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ABSTRACT 

This  thesis  examines  the  maintenance  information  system  for  the  Navy's 
air-launched  missiles,  draws  conclusions  and  makes  recommendations  on  how  a 
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capability  of  the  Naval  Air  Systems  Command  to  manage  and  support  the 
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I.   GENERAL  INTRODUCTION 

This  report  has  been  prepared  to  bring  to  the  attention  of  the  Naval  Air 
Systems  Command  (NAVAIRSYSCOM  AIR-420)  deficiencies  associated  with  its  Manage- 
ment Information  System  (MIS)  and  the  supporting  Maintenance  Data  Collection 
System  (MDCS)  and  make  recommendations  for  their  improvement. 

A.   BACKGROUND 

NAVAIRSYSCOM  (AIR-420)  is  the  Navy's  designated  systems  command  respon- 
sible for  the  logistics  support  of  Air-Launched  Missiles  (ALMs).   NAVAIRSYSCOM 
(AIR-420' s)  function  is  the  management  (planning,  programming,  directing,  and 
control)  of  field  activities  through  specific  delegated  tasks  to  accomplish 
its  mission.   Since  NAVAIRSYSCOM  (AIR-420)  does  not  own  any  missile  mainte- 
nance or  maintenance  support  activities,  execution  of  these  functions  are 
assigned  to  other  commands  (e.g.,  supply  to  Naval  Supply  Systems  Command  (NAV- 
SUPSYSCOM) ;  maintenance  to  Naval  Sea  Systems  Command  (NAVSEASYSCOM) .   This 
separation  of  management  and  engineering  from  those  activities  performing 
supply  support  and  maintenance  is  thus  complicated  by  inter-command  relation- 
ships.  One  such  example  of  these  relationships  is  MDCS.   NAVAIRSYSCOM  (AIR-420) 
has  delegated  MDCS  to  the  Fleet  Analysis  Center  (FLTAC),  a  NAVSEASYSCOM  facil- 
ity.  NAVAIRSYSCOM  (AIR-420)  has  had  difficulty  in  controlling  the  operation 
and  outputs  of  MDCS  through  delegated  tasking,  and  FLTAC  has  been  unresponsive 
in  the  execution  of  its  function. 

One  of  the  more  important  missions  of  NAVAIRSYSCOM  (AIR-420)  is  the  accomp- 
lishment of  maintenance  and  overhaul  for  the  Navy's  inventory  of  ALMs.   This 
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inventory  represents  a  large  capital  investment,  wit    le  annual  m   itena-  a 
budget  estimated  at  75  million  dollars.   The  capital  investment  and  support 
costs  combine  to  form  a  significant  ongoing  business  which  is  complex  to 
manage. 

The  maintenance  system  has  three  levels:   the  organizational,  intermediate 
and  depot  levels  of  maintenance.   The  organizational  level  is  performed  by  the 
Fleet  operational  activities.   Intermediate  maintenance  is  performed  by  NAV- 
SEASYSCOM  weapon  stations  and  Fleet  Missile  Maintenance  Facilities  (MMFs). 
Depot  level  of  maintenance  is  performed  by  the  Naval  Air  Rework  Facility  (NARF) 
Alameda  and  commercial  companies.   NAVAIRSYSCOM  sets  the  maintenance  policy 
for  the  organizational  level,  but  the  actual  work  is  done  by  Fleet  personnel. 
Intermediate  level  maintenance  is  primarily  performed  by  weapon  stations  and 
is  funded  and  managed  by  NAVAIRSYSCOM  (AIR-420)  with  the  actual  scheduling  and 
production  accomplished  by  weapon  station  personnel.   The  same  is  true  for 
depot  level  maintenance  except  the  work  is  performed  through  contracting  with 
commercial  companies  and  by  NAVAIRSYSCOM  tasking  and  funding  to  the  NARFs . 

Timely  and  accurate  information    essential  to  NAVAIRSYSCOM  management 
and  NAVAIRSYSCOM  Fleet  engineering  support  functions.   The  core  of  this  infor- 
mation is  maintenance  data.   NAVAIRSYSCOM  (AIR-420)  is  responsible  to  the  Chief 
of  Naval  Operations  (CNO)  for  accomplishment  of  its  mission.   The  performance 
of  NAVAIRSYSCOM  (AIR-420)  is  measured  by  Asset  Readiness  (AR)  in  terms  of 
specified  objectives  called  Asset  Readiness  Objectives  (AROs).   NAVAIRSYSCOM 
is  expected  to  meet  these  objectives  in  the  most  economical  manner  possible 
(reduction  of  maintenance  burden). 
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B.   STATEMENT  OF  NEED 

Inherent  in  the  efficient  accomplishment  of  the  NAVAIRSYSCOM  (AIR-420) 
mission  is  an  efficient  and  credible  MIS.   It  is  essential  that  NAVAIRSYSCOM 
(AIR-420)  and  cognizant  field  activities  have  accurate  and  timely  information 
from  all  the  decentralized  maintenance  facilities  and  activities  to  efficiently 
accomplish  their  assigned  mission.   This  accurate  and  timely  information  can 
best  be  gathered,  collated,  analyzed  and  compared  to  standards  through  the  use 
of  a  modern  MIS.   The  existing  NAVAIRSYSCOM  (AIR-420)  MIS  is  antiquatld  and 
has  many  deficiencies. 

The  development  of  an  air-launched  missile  information  system  that  is  both 
modern  and  adequate  would  benefit  the  Navy  in  terms  of  asset  readiness,  relia- 
bility of  inventory,  and  decreased  cost  of  maintenance.   Asset  readiness  would 
be  increased  by  decreasing  missile  logistics  downtime,  thereby  increasing  the 
number  of  missiles  in  Ready  For  Issue  (RFI)  condition.   Better  engineering 
decisions  would  be  possible  for  product  improvement,  which  would  increase 
inventory  reliability.   Rapid  access  to  information  would  help  management 
minimize  costly  delays  and  pinpoint  uneconomical  maintenance  actions. 

A  modern  MIS  should  have  the  capability  to  provide  real-time  reporting  and 
analysis  of  all  essential  processes  within  the  maintenance  pipeline.   A  user 
should  also  be  able  to  project  the  results  of  future  maintenance  processes 
based  on  qualitative  or  quantitative  variables.   The  information  supplied  must 
be  credible,  understandable,  and  offer  a  reward  for  its  use.   Without  these 
properties,  the  users  will  not  accept  ownership  of  the  information  and  the 
system  will  fail.   Ownership  is  best  accomplished  when  the  system  is  an 
integral  part  of  the  user's  organization.   The  significant  number  of  users 
require  that  any  new  NAVAIRSYSCOM  (AIR-420)  MIS  be  a  distributed  network  of 
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computers  so  that  all  participants  have  equal  access  and  share  responsibility 
for  the  data  and  information.   The  final  responsibility  for  operation  and 
management  of  the  information  system  should  be  within  the  NAVAIRSYSCOM 
(AIR-420)  organization  to  prevent  inter-command  conflicts. 

C.  RESEARCH  OBJECTIVES 

This  report  examines  the  characteristics  of  the  existing  MDCS  and  deter- 
mines its  potential  utility  as  the  primary  element  in  the  development  of  a 
modern  Maintenance  Management  Information  Syster   MMIS).   The  objectives  of 
the  report  are: 

1.  Determine  and  analyze  characteristics  and  capabilities  of  the  present 
MDCS  and  MIS. 

2.  Analyze  the  deficiencies  of  the  existing  MDCS. 

3.  Propose  system  properties  and  management  guidelines  for  the  development 
of  a  new  MMIS. 

4.  Develop  a  conceptual  model  for  a  modern  MMIS  as  the  primary  element  of  a 
modern  MIS. 

D.  REPORT  CONTENTS 

The  remaining  portion  of  the  report  has  been  divided  into  six  sections. 
Each  of  these  sections  is  briefly  described  to  orient  the  reader  and  assist  in 
locating  pertinent  information. 

Section  2  presents  the  major  conclusions  and  recommendations  of  the  report 
Conclusions  and  recommendations  have  been  included  as  early  as  possible  in  the 
report  to  allow  evaluation  with  a  minimum  of  effort.   Justification  is  con- 
tained in  ensuing  sections. 

Section  3  presents  a  more  detailed  background  of  Navy  maintenance  policy 
and  the  current  NAVAIRSYSCOM  (AIR-420)  MIS  structure  as  defined  in  OPNAVINST 
8600.,  The  Naval  Airborne  Weapons  Maintenance  Program  [Ref.  1].   This  material 
has  been  included  to  provide  the  reader  with  a  background  of  basic 
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NAVAIRSYSCOM  processes  which  may  be  necessary  for  the  understanding  of  sub- 
sequent sections  of  this  report. 

Section  4  is  a  historical  review  of  the  MDCS  which  details  capabilities 
and  deficiencies.   The  historical  approach  was  adopted  in  order  to  demonstrate 
how  deficiencies  emerged  and  to  emphasize  that  they  are  persistent  in  nature. 
The  persistence  of  deficiencies  indicates  that  they  are  managerial  rather  than 
technical  in  nature. 

Section  5  presents  material  of  a  conceptual  nature  concerning  the  charac- 
teristics required  for  a  new  MMIS.   This  section  contains  two  subsections. 
The  first  describes  technology  transfer  principles  which  should  be  applied  in 
the  development  of  a  new  information  system.   Although  philosophical  in  nature, 
these  principles  are  considered  more  fundamental  to  the  successful  development 
of  a  new  system  than  technical  requirements.   The  second  subsection  lists  con- 
ceptual requirements  of  a  technical  nature  for  the  new  system. 

Section  6  briefly  surveys  the  state  of  current  information  system  techno- 
logy, and  concludes  that  the  primary  potential  difficulties  in  the  development 
of  a  new  information  system  are  managerial  rather  than  technological  in  nature. 

Section  7  briefly  describes  a  management  systems  approach  which  should  be 
adopted  for  the  development  of  the  new  system. 
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II.   CONCLUSIONS  AND  RECOMMENDATIONS 

The  following  ten  subsections  present  the  major  conclusions  and  recommen- 
dations of  this  report. 

A.  MIS  IS  NOT  FUNCTIONAL 

The  MIS  is  defined  as  a  major  system  of  the  ILSS,  which  provides  the  capa- 
bility for  data  gathering,  analysis,  display,  and  reporting  in  the  management 
decision  making  process.   The  system  consists  of  five  components.   However,  in 
its  current  state  the  MIS  is  non-functional  for  the  following  reasons: 

1.  Some  components  are  not  operating; 

2.  Most  components  do  not  adequately  fulfill  their  intended  function; 

3.  All  components  do  not  interface  properly; 

4.  Components  do  not  combine  to  form  an  effective  management  information 
system. 

PMS,  ICS,  and  PRABS  are  currently  not  operational  or  have  fallen  into  dis- 
use.  Only  AWCAP  appears  to  fulfill  its  intended  function,  but  this  subsystem 
would  benefit  from  modernization.   In  a  systems  sense,  none  of  the  components 
interface  properly.   For  example,  AWCAP  and  PRABS  are  stand  alone  systems. 
PMS  and  ICS  were  clearly  designed  with  the  primary  purpose  of  interfacing  MDCS 
with  MIS.   Their  failure  isolates  MDCS  and  makes  access  unfeasible.   An  effec- 
tive MIS  cannot  be  developed  from  components  which  do  not  operated  to  fulfill 
their  intended  function  or  interface  properly.   Therefore,  NAVAIRSYSCOM  should 
begin  restructuring  the  current  MIS. 

B.  MDCS  IS  UNWORKABLE 

Since  the  MIS  is  deficient  as  an  information  system,  at  least  some  of  the 
components  which  combine  to  make  up  the  MIS  are  accordingly  unworkable.   The 
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most  important  of  these  components,  MDCS,  has  several  serious  deficiencies  and 
should  be  abandoned  as  a  means  of  monitoring  air-launched  missile  status  and 
history.   Although  the  system  basically  conforms  to  the  definitions  published 
in  the  NAWMP,  it  has  deteriorated  into  a  useless  mass  of  data,  unintelligible 
to  its  users  and  developers.   It  is  ultimately  unworkable  for  the  following 
reasons : 

1.  Users  do  not  have  direct  access  to  data  files; 

2.  Current  report  output  is  of  marginal  quality  and  reliability; 

3.  Users  have  little  or  no  data  processing  capability; 

4.  Reliability  of  data  element  definitions  is  questionable; 

5.  System  documentation  is  inadequate; 

6.  Timeliness  of  data  entry  is  still  in  question. 

More  importantly,  MDCS  lacks  credibility  with  users.   The  lack  of  user  con- 
fidence has  produced  continual  efforts  to  subvert  the  system  and  obtain  data 
by  other  means.   However,  even  if  MDCS  deficiencies  could  be  immediately  cor- 
rected, significant  user  support  could  not  be  generated  within  the  foreseeable 
future.   A  management  information  system  cannot  survive  without  the  support  of 
its  users. 

C.   DEVELOPMENT  OF  A  NEW  SYSTEM 

Considering  the  deficiencies  of  the  MDCS  listed  above,  remedial  upgrade  of 
MDCS  appears  to  be  a  more  significant  effort  than  development  of  a  new  system. 
The  development  of  a  new  system  would  avoid  the  user  bias  and  obsolete  tech- 
nology inherent  in  MDCS.   The  imposition  of  a  systems  approach  with  a  phased 
implementation  (including  proper  planning  and  evaluation)  offers  the  highest 
probability  of  success. 

The  final  goal  of  this  development  effort  should  be  a  completely  restruc- 
tured NAVAIRSYSCOM  (AIR-420)  MIS.   The  intent  of  this  report  is  more  limited 
in  scope.   The  report  recommends  that  MDCS  be  abandoned  and  replaced  with  a 
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new  component  called  the  Maintenance  Management  Information  System  (MMIS). 
The  MMIS  would  be  a  stand  alone  information  system  for  the  management  of  ALM 
maintenance.   Implementation  of  the  MMIS  will  fill  a  critical  need  in  itself. 
The  MMIS  would  also  serve  as  the  cornerstone  of  the  restructured  MIS  through 
expansion  upward  and  outward  until  all  requirements  for  management  information 
of  the  ALM  community  are  satisfied. 

D.  UTILIZATION  OF  TECHNOLOGY  TRANSFER  PRINCIPLES 

The  principles  of  technology  transfer  should  be  considered  in  the  con- 
ceptual formulation  of  the  MMIS.   In  a  general  sense,  technology  transfer 
principles  are  contained  in  nine  elements  of  the  Linker  Model  and  are  con- 
sidered necessary  for  user  acceptance  of  new  developments  or  innovations.   By 
applying  technology  transfer  principles  to  information  systems,  the  new  MMIS 
becomes  the  linker  between  the  members  of  the  ALM  maintenance  community. 
Reward  and  penalty  of  the  system  should  also  be  given  careful  attention.   In 
the  general  sense,  this  means  that  there  must  be  a  reward  for  the  use  of  an 
innovation  or  it  will  not  be  utilized.   Consequently,  products  of  the  MMIS 
must  offer  a  reward  for  their  use  to  the  members  of  the  ALM  community.   The 
reward  concept  implies  that  MMIS  conception  starts  with  the  definition  of 
products  as  opposed  to  MDCS,  which  started  with  the  definition  of  data 
elements.   The  MMIS  must  be  product  oriented. 

E.  MMIS  TECHNICAL  REQUIREMENTS 

Research  conducted  in  during  the  preparation  of  this  report  identified 
eleven  technical  requirements  of  a  conceptual  nature  which  should  be 
incorporated  in  the  MMIS. 
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1.  The  system  must  be  controllable  and  auditable. 

2.  The  system  must  have  integrity. 

3.  The  system  should  be  economical  to  operate. 

4.  The  system  must  be  user  friendly. 

5.  Data  must  be  collected  real-time  as  missile  maintenance  status  changes. 

6.  Inquiries  must  be  answered  with  up  to  the  minute  information. 

7.  The  system  must  interface  all  users  of  the  information  with  the 
suppliers  of  data. 

8.  Missile  quality  assurance  and  data  quality  assurance  must  be  linked. 

9.  The  system  must  be  fail  soft. 

10.  No  special  skills  or  extensive  schooling  should  be  required  to  run  the 
system. 

11.  User  programming  should  be  optional. 

In  addition,  the  MMIS  should  incorporate  a  Data  Base  Management  System 
(DBMS)  and  a  Decision  Support  System  (DSS).   These  systems  would  prevent  data 
redundancy  and  support  semi-structured  decision  making. 


F.  MMIS  DISTRIBUTED  NETWORK 

The  MMIS  should  be  configured  as  a  distributed  processing  system,  composed 
of  a  host  computer  servicing  a  number  of  satellite  computers.   Each  satellite 
would  be  able  to  transmit  and  receive  data  from  the  host  computer,  and  update 
host  data  files  on  a  selected  basis.   The  satellites  would  also  be  capable  of 
independent  data  processing  and  should  be  able  to  communicate  with  the  other 
computers  in  the  network.   The  host  computer  would  maintain  all  present  mis- 
sile configurations,  integrated  maintenance  histories,  present  maintenance 
status  summaries,  and  pipeline  location. 

G.  DEVELOPMENT  OF  A  MISSILE  TRAVELER 

A  missile  traveler  system  should  be  developed.   The  traveler  system  recom- 
mended in  the  report  follows  the  missile  through  the  pipeline  and  integrates 
data  collection,  quality  assurance,  and  maintenance  status  functions.   The 
traveler  would  significantly  reduce  the  paperwork  requirements  currently 
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imposed  on  maintenance  personnel  by  eliminating  missile  log  books,  config- 
uration summary  forms,  maintenance  action  forms,  and  maintenance  check  lists. 
Integration  of  the  traveler  package  with  quality  assurance  functions  should 
also  increase  data  accuracy. 

H.   PERFORMANCE  STANDARDS 

Performance  standards  should  be  incorporated  in  the  MMIS  processing  soft- 
ware to  allow  automated  management  by  exception.   There  is  a  need  to  quickly 
identify  maintenance  problems  such  as  abnormal  reject  rates  of  assets,  delayed 
processing  times,  excessive  buildup  of  non-RFI  inventories,  and  excessive 
logistics  downtime.   NAVAIRSYSCOM  (AIR-420)  developed  a  number  of  performance 
standards  covering  many  aspects  of  ALM  maintenance  processing.   However,  imple- 
mentation of  these  standards  has  been  hindered  by  the  inability  to  incorporate 
them  in  a  viable  MIS. 

I.   AVAILABLE  TECHNOLOGY 

The  conceptual  MMIS  has  no  technical  requirements  which  cannot  easily  be 
satisfied  with  existing  technology.   Therefore,  selecting  the  appropriate 
technology  becomes  a  trade  off  of  existing  technology  options  with  their 
associated  costs  for  optimization  of  the  MMIS.   The  primary  question  will  be 
between  MMIS  development  and  operation  costs,  and  benefits  to  be  achieved. 
The  benefits  should  relate  to  asset  readiness  and  the  reduction  of  maintenance 
burden. 
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J.   MMIS  OWNERSHIP 

NAVAIRSYSCOM  (AIR-420)  must  maintain  ownership  and  control  of  the  MMIS  to 
ensure  the  success  of  the  system.   From  a  practical  standpoint,  NAVAIRSYSCOM 
(AIR-420)  cannot  assume  control  of  computer  systems  of  other  commands  nor 
should  it  delegate  the  operation  of  its  system  to  other  commands.   A  field 
activity  such  as  PACMISTESTCEN  would  be  an  excellent  choice  for  the  develop- 
ment of  the  MMIS  since  this  activity  is  a  primary  user  of  ALM  maintenance 
information.   The  MMIS  should  be  developed  and  operated  by  the  activity  that 
it  is  primarily  designed  to  support.   In  the  author's  opinion,  this  is  an 
activity  delegated  responsibility  for  ALM  maintenance  management:   PACMIS- 
TESTCEN.  Three  critical  benefits  are  obtained  by  giving  MMIS  to  its  primary 
user.   First,  this  user  will  strive  to  ensure  system  success  because  of  the 
rewards  offered.   Second,  the  user  is  in  the  best  position  to  integrate  infor- 
mation system  functions  with  management  functions.   Third,  this  user  would  be 
forced  to  accept  ownership  of  the  information  and  would  thus  eliminate  contro- 
versy as  to  what  information  is  pertinent. 
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III.   DETAILED  BACKGROUND 

A.   NAVY  MAINTENANCE  POLICY 

The  Navy's  current  maintenance  policies  follow  three  ideas:   the  All-Up-Round 
(AUR)  maintenance  concept,  tri- level  maintenance,  and  achievement  of  the  ARO. 
The  AUR  concept  attempts  to  deliver  a  missile  to  an  operational  squadron  in  the 
simplest,  most  reliable  manner  possible.   Using  the  AUR  concept,  operational 
Fleet  squadrons  perform  only  minor  assembly  before  installing  the  missile  on  the 
launch  platform.   In  turn,  the  AUR  concept  allows  shore  activities  to  validate 
the  status  and  condition  of  the  missile  with  a  minimal  expenditure  of  labor, 
time,  and  money.   The  maintenance  pipeline  splits  ALM  maintenance  into  three 
levels.   The  extent  of  maintenance  needed  determines  the  number  of  levels 
required  to  ultimately  accomplish  repair. 

The  first  level,  Organizational  Level  Maintenance  (OLM) ,  encompasses  the 
maintenance  performed  by  Fleet  operational  squadrons.   O-level  maintenance 
generally  consists  of  missile  receipt,  inspection,  aircraft  preparation,  loading 
and  downloading,  basic  functional  aircraft  checks,  and  installation  and  removal 
of  wings  and  fins . 

The  second  level,  Intermediate  Level  Maintenance  (ILM),  encompasses  the 
maintenance  performed  by  an  Intermediate  Maintenance  Activity  (IMA):   a  Naval 
weapon  station  or  MMF.   The  IMA  supports  the  operational  squadron  by  providing 
an  AUR  that  is  ready  for  launch  except  for  the  attachment  of  wings  and  fins. 
I-level  maintenance  personnel  conduct  AUR  tests  of  the  assembled  missile  and 
replace  defective  missile  sections.   Missile  sections  requiring  maintenance 
beyond  I-level  capability  are  sent  to  the  Depot  level  maintenance.   In  addition, 
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the  I -level  unpacks  and  inspects  AURs  and  sections,  and  repacks  them  when 
testing  and  cleaning  have  been  completed. 

Depot  Level  Maintenance  is  conducted  at  activities  called  Designated 
Overhaul  Points  (DOP) .   At  this  level,  individual  parts  and  subassemblies  are 
replaced  in  sections  that  failed  I-level  tests  and  inspections.   In  addition, 
special  maintenance  actions,  such  as  the  regraining  of  rocket  motors,  are  per- 
formed at  the  DOP.   Completing  the  maintenance  cycle,  the  DOP  provides  the 
weapon  station  with  repaired  sections  which  are  ready  for  assembly  into  an  AUR. 

Every  year  the  CNO  establishes  the  ARO,  which  serves  as  the  goal  to  be 
achieved  and  maintained  by  the  entire  maintenance  community.   Asset  Readiness 
(AR)  is  a  fluctuating  figure  which  specifies  NAVAIRSYSCOM  (AIR-420)  performance 
of  given  missile  inventory.   It  is  expressed  as  the  ratio  between  serviceable 
missile  assets  and  the  total  numnber  of  assets  in  this  inventory.   Thus,  the 
less  time  a  missile  spends  in  the  maintenance  pipeline,  the  higher  the  asset 
readiness  figure. 

The  central  point  in  the  pipeline  is  the  weapon  station.   Here,  new  mis- 
sile sections  from  manufacturers  are  inspected  and  assembled  into  AURs.   Fleet 
return  AURs  are  also  received  for  periodic  tests  and/or  maintenance.   After 
assembly  and  testing,  or  testing  and  maintenance,  the  AURs  are  packaged  in 
containers  for  shipment. 

AURs  are  provided  to  the  carriers  from  weapon  stations'  RFI  stocks.   The 
missiles  are  generally  loaded  on  board  a  service  force  ship  and  transported  to 
the  aircraft  carrier  where  they  are  transferred  by  vertical  replenishment  and 
stored  in  magazines  in  their  AUR  containers.   During  a  deployment,  the  carrier 
unpacks  only  enough  missiles  for  self-defense,  usually  about  twenty  percent  of 
the  on  board  air-to-air  missiles.   Carrier  deployments  are  approximately  one  year 
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While  returning  to  home  port  at  the  end  of  the  deployment,  the  carrier  will 
undergo  a  Missile  Pre-sentencing  Inspection  (MPI),  known  as  Missile  Sentencing 
Inspections  (MSIs)  prior  to  1979,  which  evaluates  the  serviceability  of  all 
missiles  on  the  carrier,  thus  reducing  processing  at  the  weapon  station.   Dur- 
ing the  MPI,  missiles  are  segregated  according  to  another  concept  that  is  vital 
not  only  to  the  maintenance  pipeline,  but  also  to  the  MDCS  itself.   The  concept 
of  Serviceable-In-Service-Time  (SIST)  indicates  the  maximum  period  of  time  a 
deep  stowed  missile  may  remain  in  storage  before  it  must  be  returned  to  a  wea- 
pon station  for  periodic  test.   As  will  be  discussed  later,  the  concept  of  SIST 
significantly  changed  the  Navy's  maintenance  policy. 

Using  SIST  and  the  corresponding  Maintenance  Due  Date  (MDD) ,  personnel 
conducting  the  MPI  segregate  serviceable  missiles  from  the  unserviceable. 
Those  which  were  captive  carried,  have  an  expired  MDD,  or  insufficient  SIST 
remaining  for  another  deployment  are  pre-sentenced  to  be  returned  for  weapon 
station  testing.   Deep-stowed  missiles  which  have  sufficient  SIST  remaining 
for  the  next  carrier  deployment  are  crossdecked  to  another  carrier.   Hence, 
the  MPI  screens  the  serviceable  missiles  for  Fleet  retention  rather  than 
returning  the  carrier's  entire  inventory  to  the  weapon  station. 

Those  missiles  which  require  processing  are  then  moved  to  the  IMA  where 
they  are  tested  as  AURs .   If  they  pass,  they  are  returned  to  RFI  storage.   If 
they  fail,  the  section  causing  the  failure  is  isolated  and  replaced.   The 
defective  section  is  then  shipped  to  the  depot  for  overhaul. 

At  the  depot  the  section  is  repaired  and  shipped  back  to  the  weapon  sta- 
tion for  assembly  into  another  AUR  or  as  a  replacement  spare.   The  time  that 
missiles  and  missile  sections  are  in  the  repair  pipeline  is  determined  by  the 
efficiency  of  the  maintenance  system  since  individual  test  and  repair  actions 
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are  accomplished  in  a  matter  of  hours.   The  number  of  weapons  in  the  pipeline 
at  any  one  time  depends  on  the  number  of  missiles  which  are  sentenced  as 
unserviceable  and  the  elapsed  time  required  to  return  them  to  RFI  condition. 

B.   NAWMP  DEFINITIONS 

In  the  early  1980s,  NAVAIRSYSCOM  (AIR-420)  developed  the  Naval  Airborne 
Weapons  Maintenance  Program  (NAWMP),  which  serves  to  fully  document  mainte- 
nance policy  for  ALMs  under  the  cognizance  of  AIR-420.   This  report  examines 
the  structure  of  AIR-420* s  management  system,  the  Integrated  Logistics  Support 
System  (ILSS),  but  concentrates  on  one  ILSS  element,  the  Management  Information 
System  (MIS)  and  its  subordinating  components.   Definitions  of  the  ILSS,  MIS, 
and  subsidiary  subsystems  have  been  extracted  from  the  NAWMP  in  an  effort  to 
compare  the  way  these  systems  were  designed  to  operate  and  their  actual 
operation  today. 

The  ILSS  [Ref.  2]  was  instituted  in  the  early  1970s  as  a  means  of  decentra- 
lizing AIR-420 's  logistics  functions.   The  ILSS  is  comprised  of  five  systems, 
the  primary  system  being  the  MIS.   As  defined  in  the  NAWMP,  "The  MIS  provides 
a  capability  for  data  gathering,  analysis,  display  and  reporting  which  is  used 
by  management  personnel  in  the  decision  making  process"  [Ref.  3] .   The  system 
consists  of  five  components  which  together  are  supported  to  provide  an  auto- 
mated maintenance  monitoring  capability.   The  first,  the  Problem  Reporting  and 
Briefing  System  (PRABS)  is  a  "semi-automated  management  information,  quick- 
reaction  reporting  system  which  provides  procedures  for  collecting  and 
reporting  significant  active  problems  and  proposed  solutions"  [Ref.  4]. 

The  Airborne  Weapons  Corrective  Action  Program  (AWCAP)  system  is  owned  and 
operated  by  the  Pacific  Missile  Test  Center  (PACMISTESTCEN) .   It  is  used  to 
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accumulate  and  track  maintenance  deficiencies  of  all  air-launched  missile 
systems  and  selected  airborne  ordnance/ ammunition  commodities.   Problems  are 
reported  through  Quality  Deficiency  Reports  (QDRs),  Engineering  Investigation 
Requests  (EIRs),  and  Safety  Reports  submitted  by  Fleet  and  shore  based  mainte- 
nance activities.   The  AWCAP  report  summarizes  all  active  problems  and  reflects 
the  progress  of  the  investigation,  including  any  corrective  actions  taken. 

The  third  MIS  component  is  the  Maintenance  Data  Collection  System  (MDCS), 
the  primary  maintenance  data  system  for  air-launched  missiles.   According  to 
the  ILSS,  this  system  "provide[s]  a  single  source  of  maintenance  data  to  remote 
and  local  data  users,"  and  also  "collect[s]  and  store[s]  as  much  detailed  main- 
tenance data  as  can  be  reasonably  obtained,  while  adhering  to  a  simple,  easy 
to  understand  data  collection  procedure"  [Ref.  5].   As  the  Central  Data 
Collection  Agency  (CDCA) ,  FLTAC  designed  and  distributes  forms  for  recording 
and  transmittal  of  specific  information  regarding  each  reportable  action.   In 
accordance  with  the  basic  precept  of  MDCS,  data  is  hand  written  on  the  form. 

As  defined  in  the  NAWMP,  the  last  two  segments  of  the  MIS  are  two  on-line 
data  distribution  systems  presently  operational  at  FLTAC.   The  Performance 
Monitoring  System  (PMS)  has  been  designated  as  the  "primary  mode  for  presenting 
and  distributing  logistic  management  information"  [Ref.  6].   The  PMS  maintains 
on-line  displays  available  for  logistics  management  users  possessing  remote 
terminal  access.   Through  remote  terminals,  users  can  request  summarized  PMS 
data  displays,  including  Mean  Downtime,  Part  Replacement  Rates,  and  ALM 
processing  rates. 

The  second  information  distribution  system,  the  Information  Consolidation 
Service  (ICS),  has  been  established  as  a  method  of  "deriving  selected  infor- 
mation by  the  user... from  data  stored  in  the  Integrated  Data  Base"  [Ref.  7]. 
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ICS  integrates  the  files  of  maintenance  data  with  related  reference  files  of 
supply  oriented  data.   ICS  outputs  include  summary  reports  and  displays 
reflecting  maintenance  trends,  reject  rates,  and  average  maintenance  time. 

Although  the  definitions  and  procedures  of  the  MIS  have  been  clearly 
outlined  in  the  NAWMP,  the  system  is  inoperable  for  reasons  that  will  be 
discussed  in  the  next  section  of  this  report.   The  current  Management 
Information  System  is  not  answering  the  needs  of  the  Navy's  maintenance 
community.   The  time  has  come  to  begin  a  change. 
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IV.   HISTORICAL  REVIEW  OF  MDCS 

A.  MAINTENANCE  DATA  COLLECTION  SYSTEM 

The  MDCS  component  of  the  MIS  was  designed  and  is  operated  by  FLTAC,  for- 
merly the  Fleet  Missile  System  Analysis  and  Evaluation  Group  (FMSAEG) .   Its 
development  stems  from  the  late  1960s  as  a  response  to  OPNAVINST  4790.,  which 
called  for  an  effective  Maintenance  and  Material  Management  (3M)  Program  for 
air-launched  missile   and  targets.   Al enough  the  NAWMP  states  that  MDCS  was 
developed  as  part  of  che  ILSS,  design  concepts  for  MDCS  predate  the  ILSS  by  an 
undefined  period  of  time.   Revision  2  of  the  ILSS  Program  Master  Plan  states 
that  at  the  beginning  of  the  program  MDCS  was  "fully  defined"  and  design 
(development)  would  begin  immediately.   At  that  time,  the  NAVAIRSYSCOM  (AIR-420) 
organization  was  known  as  NAVAIRSYSCOM  (AIR-4104) .   AIR-4104  began  developing 
the  ILSS  in  1972  as  a  means  of  defining  and  systematizing  ALM  maintenance 
management  functions.   The  ILSS  program  was  instituted  to  decentralize  and 
delegate  authority  of  NAVAIRSYSCOM  functions  to  cognizant  field  activities. 
Although  in  its  infancy,  MDCS  was  one  of  these  existing  functions. 

B.  MDCS  CAPABILITIES 

MDCS  had  originally  been  conceived  as  an  entity  in  itself.   At  the  time, 
however,  little  attention  was  given  to  the  possibility  of  interaction  between 
the  various  data  systems  of  the  MIS.   Primary  emphasis  was  placed  on  data 
collection,  while  data  processing  and  information  output  were  secondary 
considerations.   Nevertheless,  it  was  the  ILSS  which  later  defined  MDCS  as 
p  t   of  the  NAVAIRSYSCOM  (AIR-4104)  MIS.   As  will  be  discussed  later,  little 


28 


effort  was  expended  in  restructuring  MDCS  itself.   It  was  simply  inserted  as  a 
component  for  the  newly  developed  MIS.   The  additional  requirements  for  inter- 
facing data  processing  and  information  output  components  were  imposed  on  the 
two  new  elements,  PMS  and  ICS.   This  decision  lies  at  the  very  heart  of  the 
controversies  concerning  the  validity  and  utility  of  MDCS:   does  MDCS  fulfill 
its  design  function? 

The  answer  to  this  question  is  a  hesitant  yes,  although  with  great  diffi- 
culty and  much  uncertainty.   PMS  and  ICS  are  acknowledged  failures,  and  without 
any  data  processing  or  information  output  capability,  MDCS  cannot  stand  alone. 
Further,  without  these  functions,  the  merit  of  the  data  within  MDCS,  and  there- 
fore the  merit  of  MDCS  itself  cannot  be  rationally  evaluated.   MDCS  is  an 
antiquated  system  in  dire  need  of  revision.   Its  current  lack  of  credibility 
and  the  significant  level  of  user  bias  favors  the  development  of  a  new  system 
rather  than  extensive  revision  of  the  existing  system.   The  technology  avail- 
able also  makes  it  desirable  to  redefine  the  MDCS's  function  so  that  it  becomes 
an  interactive  element  of  a  future  MIS  network  vice  a  data  collection  system. 

C.   MDCS  DOCUMENTATION 

Program  documentation  from  the  early  period  of  MDCS  development  is  scarce. 
However,  interviews  with  individuals  involved  with  ALM  maintenance  at  the  time 
indicate  that  a  systems  approach  was  taken  in  an  effort  to  collect  all  perti- 
nent data.   MDCS  was  subdivided  into  three  parallel  subsystems  to  mirror  the 
maintenance  pipeline. 

1.    Shore  Activity  MDCS 

The  first  and  most  important  of  the  three  subsystems  was  Shore 
Activity  Maintenance  Data  Collection.   The  Shore  Activity  MDCS  was  designed  to 
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collect  data  concerning  maintenance  actions  on  air-launched  missiles  at  the 
weapon  stations  and  MMFs  (the  current  MMF  is  located  at  Naval  Air  Station  Cubi 
Point) . 

2.  Fleet  Maintenance  MDCS 

The  second  level,  Fleet  Maintenance  Data  Collection,  was  designed  to 
collect  maintenance,  quality  surveillance,  and  logistic-oriented  data  on 
air-launched  missiles  in  the  custody  of  the  operational  Fleet,  including  Naval 
and  Marine  Corps  air  stations. 

3.  Depot  MDCS 

The  third  level,  Depot  Maintenance  Data  Collection,  was  designed  to 
collect  overhaul  and  repair  data  for  all  air-launched  missile  guidance  and 
control  sections  being  maintained  at  various  NARFs  and  contractors.   FLTAC 
achieved  varying  levels  of  success  in  the  development  and  implementation  of 
the  three  subsystems.   Primary  emphasis  was  placed,  and  the  greatest  amount  of 
success  was  achieved,  with  the  Shore  MDCS  subsystem.   General  references  to 
MDCS  are  primarily  directed  at  the  Shore  based  MDCS  subsystem. 

D.   MDCS  DATA 

In  the  early  1970s,  FLTAC  began  surveying  individuals  involved  with  ALM 
maintenance  to  identify  applicable  data  elements  to  be  included  in  MDCS.   A 
major  mistake  in  the  development  of  the  system  was  made  at  this  time.   After 
interviewing  maintenance  managers  and  engineers,  a  great  deal  of  "pertinent" 
data  elements  were  compiled.   However,  very  little  consideration  was  given  to 
the  actual  utility  of  each  of  these  data  elements,  or  how  the  elements  could 
be  combined  to  produce  meaningful  reports.   In  addition  to  the  interviews, 
OPNAVINST  4790.  strongly  influenced  the  definition  of  data  elements.   For 
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instance,  the  instruction  required  that  each  individual  missile  program  be 
idenified,  along  with  a  capability  to  interface  with  other  missile  related 
data  programs.   Routine  and  corrective  maintenance  had  to  recorded,  in 
addition  to  referencing  technical  directives,  and  the  establishment  of 
logistic  audit  procedures. 

These  surveys  resulted  in  two  essentially  standardized  computer  record 
formats.   This  first  record  format  characterized  maintenance  actions,  such  as 
inspection,  test,  repair,  and  assembly  of  missiles  and  sections.   The  second 
record  format  characterized  the  configuration  of  built-up  missiles.   This 
included  the  part  numbers  of  major  components  and  service  life  information. 
Figure  1  lists  data  elements  for  the  PHOENIX  maintenance  action  record  format. 
As  can  be  seen,  this  record  was  long  and  complex.   The  PHOENIX  maintenance 
action  record  contained  46  possible  elements  or  fields  with  a  maximum  of  720 
characters.   The  size  and  complexity  of  the  record  led  to  some  of  the  problems 
encountered  with  MDCS.   First,  the  record  placed  excessive  demands  upon  the 
individuals  who  were  supposed  to  record  the  data.   Maintenance  personnel  con- 
sidered missile  maintenance  to  be  their  primary  function  and  felt  that  data 
entry  was  an  imposition.   Second,  some  of  the  elements  within  the  record  could 
not  be  easily  obtained  on  the  weapon  station  floor.   For  example,  the  third 
data  element  called  for  the  National  Item  Identification  Number  (NUN),  and 
would  be  skipped  if  it  was  not  directly  accessible  to  processing  personnel. 
Elements  such  as  the  NUN  were  probably  meant  to  be  completed  at  later  stages 
in  the  data  collection  process.   At  any  rate,  the  practice  resulted  in  the 
generation  of  records  with  many  missing  elements. 

A  second  problem  involved  with  the  MDCS  records  was  that  their  size  made 
physical  inspection  and  comprehension  difficult.   Neither  CRT  displays  nor 
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printers  could  provide  the  data  in  a  single  line  format,  making  it  very  diffi- 
cult to  interpret.  To  compound  the  problem,  software  from  the  UNIVAC  computer 
was  used  to  compress  the  data.  FLTAC  programmers  employed  the  symbol  (@)  as  a 
means  of  condensing  the  record.  For  example,  if  the  first  two  data  elements 
in  a  record  were  the  serial  number  and  Naval  Ammunition  Logistics  Code  (NALC) , 
and  the  third  data  element,  the  NUN,  was  unknown,  the  record  would  look  like 
this:   @20125@PA55@@. 

From  the  standpoint  of  data  storage,  this  process  had  significant  merit 
since  these  records  could  now  be  allocated  a  fraction  of  the  space  that  they 
normally  required.   However,  without  some  form  of  intermediary  processing,  the 
records  became  unintelligible.   With  46  data  elements,  particular  blocks  of 
data  were  scattered  at  varying  locations  within  the  record.   If  ten  consecutive 
data  elements  were  skipped,  for  whatever  reason,  eleven  consecutive  symbols 
would  be  printed,  making  the  actual  data,  what  little  there  was,  very  difficult 
to  read.   This  practice  of  data  compression  and  the  limited  distribution  of 
record  format  led  to  the  development  of  an  elite  corps  of  FLTAC  analysts  who 
could  translate  the  data.   In  effect,  the  data  was  scrambled  and  without  rela- 
tively large  machines  and  proper  coding,  it  could  not  be  deciphered. 

E.   MDCS  DATA  COLLECTION 

Data  collection  for  the  MDCS  subsystems  was  accomplished  through  multi- 
copy forms.   Figures  2  and  3  are  facsimiles  of  the  forms  used  for  SPARROW 
maintenance  actions  and  configuration  summaries  for  shore  activities.   It  was 
originally  intended  that  personnel  directly  involved  with  missile  maintenance, 
afloat  and  ashore,  fill  out  the  forms,  although  this  idea  was  quickly  compro- 
mised.  Carrier  magazines  were  overcrowded  and  working  conditions  were  poor. 
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Ordnancemen  recorded  the  minimum  essential  data  in  pocket  notebooks  to  be 
transcribed  later  to  the  MDCS  forms  by  yeomen  in  Airborne  Ordnance  Control 
offices  for  eventual  delivery  to  FLTAC.   Naval  weapon  stations  had  developed 
their  own  paperwork  (at  first  in  the  form  of  local  worksheets  and  later  as 
checklists  adapted  from  particular  maintenance  manuals)  to  monitor  their 
internal  maintenance  processing.   Thus,  the  weapon  stations  considered  MDCS 
paperwork  as  not  only  an  imposition,  but  also  needless.   In  addition,  a  sub- 
stantial portion  of  the  data  on  the  forms  was  codified  in  order  to  standardize 
compression  and  facilitate  data  manipulation.   Again,  the  codification  was 
highly  desirable,  and  to  a  certain  extent  necessary,  but  it  produced  an  extrem- 
ely unfriendly  system.   Few  individuals  knew  what  Julian  date  it  was  or  what 
the  Julian  date  would  be  in  nine  months,  which  was  a  required  reporting  element 
in  many  cases.   Due  to  the  codification  and  the  additional  paperwork,  the  wea- 
pon stations  developed  strong  biases  against  MDCS. 

As  a  result,  the  weapon  stations  began  designating  "specialists"  to  com- 
plete the  MDCS  forms.   These  individuals  were  sometimes  stationed  away  from 
the  processing  floor  and  often  lost  some  understanding  of  the  actual  mainte- 
nance being  performed.   Their  job  was  simply  to  transcribe  data  from  one  form 
to  another.   But  due  to  a  certain  apathy  among  processing  personnel,  inaccura- 
cies often  occurred  during  the  translation. 

As  mentioned  earlier,  the  basic  MDCS  data  forms  were  in  multicopy  format 
using  a  carbon  paper-like  transfer  process.   Actually,  the  forms  were  impreg- 
nated with  a  transfer  medium  whose  density  was  less  than  desirable  since  most 
copies  were  difficult  to  read.   The  configuration  summary  forms  had  one  origi- 
nal, which  was  sent  to  FLTAC,  and  four  copies.   Of  the  copies: 
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1.  One  was  included  as  documentation  kept  with  the  particular  AUR  or 
missile  section; 

2.  One  was  kept  at  the  weapon  station  missile  maintenance  processing 
building  for  approximately  90  days; 

3.  One  was  kept  at  the  weapon  station  data  processing  offices  for  several 
years ; 

4.  One  was  usually  destroyed. 

The  copies  acted  as  a  safety  measure  to  insure  that  data  was  not  lost.   The 
use  and  distribution  of  the  copies  had  significant  impact  on  future  utility  of 
the  ICS  module  of  the  NAVAIRSYSCOM  MIS.   When  troubles  developed  in  ICS,  weapon 
station  personnel,  maintenance  engineers,  and  maintenance  managers  turned  direct' 
ly  to  these  hard  copy  MDCS  files  for  direct  access  to  data.   To  this  day,  direct 
access  to  these  hard  copy  files  is  one  of  the  most  valuable  although  unofficial 
sources  of  MDCS  data.   In  a  way,  use  of  these  files  may  have  relieved  some  pres- 
sure on  ICS  since  vital  information  was  ultimately  obtained  and  problems  were 
solved.   On  the  other  hand,  use  of  these  files  probably  increased  criticism  of 
ICS,  since  users  were  quick  to  point  out  that  the  data  was  available  but  could 
not  be  accessed  within  FLTAC's  data  banks.   It  soon  became  apparent  that  if 
you  dug  hard  enough,  you  could  find  the  data  you  needed;  but  more  importantly, 
FLTAC  did  not  have  the  data  in  the  MDCS. 

F.   DATA  STANDARDIZATION 

Considerable  effort  was  expended  to  standardize  data  between  different 
commodities.   Data  formats  were  essentially  cloned.   Certain  fields  were 
redesignated  and  coded  to  match  specific  missile  configurations,  performance/ 
test  attributes,  and  endemic  missile  problems.   It  is  not  clear  how  well  these 
data  collection  formats  mirrored  the  actual  missile  processing  procedures  at 
that  time.   It  is  evident,  however,  that  maintenance  processing  changed  over 
the  years,  and  that  the  data  collection  forms  were  not  effectively  modified  to 
reflect  these  changes.   The  layout  of  the  forms  suggests  that  major  emphasis 

34 


was  placed  on  the  logic  of  their  development.   The  forms  are  systematic  and 
appear  to  be  complete.   Nevertheless,  approval  of  the  forms  seems  to  have  been 
based  solely  on  their  logical  appearance  and  apparent  completeness  rather  than 
rigorous  user  proof  testing.   While  the  logical  steps  of  maintenance  process- 
ing are  apparent,  there  are  no  clear  definitions  of  the  actual  maintenance 
procedures.   For  instance,  processing  personnel  were  told  to  fill  out  a  form 
every  time  a  missile  was  tested,  although  the  actual  meaning  of  the  word 
"test"  was  not  clearly  defined.   Later  studies  showed  severe  discrepancies 
between  the  data  of  the  three  weapon  stations  [Ref .  8] .   Today,  the  antiquated 
format  and  the  tendency  not  to  fully  complete  records  leads  to  significant 
losses  of  vital  data. 

G.   CHANGING  MAINTENANCE  POLICY 

It  is  appropriate  at  this  point  to  digress  and  discuss  missile  maintenance 
in  the  early  1970s  and  its  impact  on  the  MDCS  subsystems.   One  of  the  primary 
contentions  of  this  report  is  that  a  basic  system  and  the  management  informa- 
tion system  designed  for  that  system  are  intimately  related.   The  management 
information  system  must  mirror,  summarize,  and  predict  the  outcome  of  the  proc- 
esses inherent  in  the  basic  system.   It  follows  that  if  the  processes  within  a 
system  change,  its  management  information  system  should  be  modified  accordingly. 

H.   IMPROVED  REARMING  RATE  PROGRAM  (IRRP) 

One  of  the  biggest  changes  in  maintenance  policy  occurred  in  1966  when  CNO 
instituted  the  IRRP.   Many  features  of  this  program  impacted  ALM  maintenance. 
For  the  first  time,  missile  inventories  were  stored  as  AURs .   Except  for 
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Missile  On  Aircraft  Tests  (MOAT),  maintenance  and  testing  of  missiles  in  the 
Fleet  was  eliminated.   In  addition,  missiles  were  tested  as  AURs  at  the  weapon 
stations.   The  benefits  of  the  IRRP  were  many,  and  their  impact  on  ALM  mainte- 
nance was  significant,  if  delayed.   The  IRRP  was  prolonged  since  its  essential 
features  required  major  modification  of  aircraft  carriers.   IRRP  capability 
was  immediately  incorporated  in  aircraft  carriers  built  subsequent  to  1966. 
Retrofit  of  existing  carriers  took  much  longer,  the  last  being  the  USS  INDEPEN- 
DENCE in  1981.   The  transition  from  section  to  AUR  based  maintenance  was  a 
gradual  one,  taking  place  throughout  the  1970s,  both  in  the  Fleet  and  at  the 
weapon  stations. 

The  first  major  impact  of  the  IRRP  was  the  virtual  elimination  of  the 
majority  of  Fleet  I-level  maintenance.   While  it  took  some  time  to  convert 
over  to  the  AUR  concept,  it  was  obvious  from  the  start  of  MDCS  development 
that  Fleet  MDCS  subsystem  requirements  had  been  minimized.   If  there  was  no 
ALM  maintenance  performed  in  the  Fleet,  then  there  was  little  requirement  to 
have  a  system  to  collect  data  concerning  that  maintenance.   While  data  forms 
and  an  instructional  manual  were  developed  for  the  Fleet  MDCS,  in  reality  it 
was  never  really  implemented.   Type  Commands  resisted  implementation  of  Fleet 
MDCS  even  in  those  Fleet  units  which  were  still  performing  significant  amounts 
of  Fleet  I-level  maintenance.   Although  the  Marines  were  purportedly  testing 
all  SPARROW  assets  in  their  possession  at  90  day  intervals,  a  survey  of  MDCS 
files  for  the  years  1974  and  1975  identified  only  three  appropriate  records. 
MSIs  aboard  carriers  for  the  period  1976  through  1980  continually  revealed  the 
absence  of  any  MDCS  documentation  in  the  Fleet. 
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I.   TEST  PRIOR  TO  ISSUE  (TPI) 

In  the  early  1970s,  ALM  maintenance  was  dominated  by  a  scheduled  mainte- 
nance requirement  defined  as  TPI.   The  TPI  requirement  specified  that  weapon 
stations  only  issue  RFI  assets  to  the  Fleet  which  had  previously  been  tested 
within  a  specified  period  of  time,  usually  180  days.   This  requirement  pre- 
vented the  stockpile  of  RFI  missiles  and  forced  weapon  station  workloads  into 
a  cyclical  pattern  in  order  to  meet  specified  carrier  onload  requirements.   In 
effect,  the  TPI  requirement  prevented  the  centralization  of  ALM  maintenance 
management.   In  addition,  weapon  stations  were  forced  to  work  with  stocks  on 
hand  (both  RFI  and  non-RFI  assets)  to  meet  loadout  requirements.   Except  for 
budgeting  constraints,  weapon  stations  operated  in  a  more  or  less  autonomous 
fashion.   Neither  NAVAIR  nor  its  designated  agents  had  a  significant  amount  of 
control  over  the  actual  scheduling  of  ALM  processing  at  the  weapon  stations. 
Under  this  mode  of  processing,  weapon  stations  operated  comfortably,  although 
inefficiently,  using  their  own  internal  files,  information  systems,  and 
sometimes  physical  inventory  of  magazines. 

The  requirements  for  Shore  MDCS  under  the  TPI  mode  of  operation  were  really 
not  very  significant  since  it  did  not  have  any  management  information  function 
at  all.   Weapon  stations  operated  autonomously  and  had  their  own  data  files. 
Missile  processing  had  become  almost  automatic:   all  missile  sections  were 
tested  prior  to  issue.   Consequently,  the  weapon  stations  had  little  need  for 
any  additional  data  except  the  explosive  component  service  life  information. 
Reporting  of  missile  processing  was  accomplished  via  subsystems  other  than 
MDCS.   Under  the  TPI  mode  of  operation,  Shore  MDCS  functions  appeared  to 
collect  data  which  could  used  for  specialized  investigative  analyses  (e.g., 
how  many  missiles  were  currently  configured  with  rocket  motors  that  would 
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expire  in  the  next  year).   There  was  some  intent  to  use  MDCS  data  to  charac- 
terize maintenance  pipeline  processes,  but  this  was  more  historical  in  nature 
(e.g.,  26  percent  of  the  guidance/control  groups  tested  on  DPM-7  test  set 
serial  number  10  failed  during  FY-76). 

J.   MDCS  DECENTRALIZATION 

At  this  point,  the  relationship  between  the  NAVAIRSYSCOM  (AIR-4104) ,  now 
NAVAIRSYSCOM  (AIR-420) ,  ILSS  and  the  underlying  MIS  with  its  MDCS  component 
merits  discussion.   The  ILSS  is  best  described  by  Revision  2  of  the  Program 
Master  Plan,  which  was  first  approved  in  December  1974.   With  ILSS,  NAVAIR- 
SYSCOM (AIR-4104)  attempted  to  define  its  functions  so  that  they  could  be 
decentralized  to  field  activities.   The  ILSS  Program  Master  Plan  takes  a  for- 
mal systems  engineering  approach  in  the  definition  and  control  of  subsystems. 
The  ILSS  and  its  subsystems  were  given  life  cycles  similar  to  hardware.   A 
subsystem's  life  cycle  phases  were  related  within  a  Work  Breakdown  Structure 
(WBS)  matrix.   The  phases  within  the  ILSS  life  cycle  were: 

1.  Research  WBS  1000 

2.  Analysis  and  Integration  WBS  2000 

3.  Design  WBS  3000 

4.  Operation  and  Evaluation  WBS  4000 

5.  Full  Scale  Implementation  WBS  5000 

6.  Maintenance  and  Control  WBS  6000 

The  revision  stated  that  the  first  three  phases  (with  certain  exceptions) 
had  been  completed  and  that  the  "major  tasks  to  be  accomplished  were  in  opera- 
tion and  evaluation,  full  scale  implementation  and  maintenance  control"  [Ref.  9] 
Specifically,  MDCS  was  one  of  the  ongoing  "reporting"  systems  which  had  success- 
fully completed  development  concurrently  with  the  research  phase  of  ILSS  (1972) 
By  1974,  the  planning  for  the  remaining  phases  of  ILSS  was  extensive.   The  com- 
pletion of  the  test  and  evaluation  phase  (WBS  4000)  required  documentation 
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validation,  specification  validation,  and  performance  and  demonstration  at  both 
the  system  and  subsystem  levels,  along  with  a  final  assessment.   The  WBS  tended 
to  imply  that  deficiencies  uncovered  during  test  and  evaluation  would  be  cor- 
rected prior  to,  or  during  the  full  scale  implementation  phase.   NAVAIRSYSCOM 
(AIR-4104)  selected  four  problems  to  demonstrate  ILSS  capability: 

1.  NWS  and  NARF  workload  coordination; 

2.  Inventory  projection; 

3.  Evaluation  of  changing  maintenance  concepts  at  NWS; 

4.  Engineering  Change  Proposal  (ECP)  evaluation. 

These  problems  were  to  be  demonstrated  on  the  SHRIKE  and  SPARROW  missile 
systems,  and  the  BQM-34  target  system.   The  preparation  of  the  system  level 
demonstration  plans  and  procedures  was  to  require  completion  of  subsystem 
demonstrations  and  preparation  of  subsystem  inputs  to  the  system  level  demon- 
stration plans.   WBS  4131  was  supposed  to  demonstrate  that  "the  MDCS  is  capable 
of  providing  the  correct  information  from  all  maintenance  levels"  Ref.  [10]. 
These  words  infer  that  it  was  known  at  the  time  that  MDCS  did  not  provide  the 
correct  information  from  all  maintenance  levels  since  Fleet  and  Depot  MDCS 
were  inoperative,  but  perhaps  had  the  potential  of  providing  such  information. 

K.   ALM  AVAILABILITY  PROGRAM 

The  true  state  of  MDCS  at  the  end  of  1974  cannot  be  determined.   Tests  and 
demonstrations  of  the  system  were  apparently  never  run.   The  ILSS  program 
appeared  to  be  generating  excessive  expense  and  absorbing  a  considerable  amount 
of  top  management  effort  during  a  period  of  congressional  concern  over  defense 
spending.   Moreover,  the  mandate  to  decentralize  NAVAIRSYSCOM  (AIR-4104)  func- 
tions had  by  this  time  lost  considerable  impetus.   In  fact,  during  1975  and 
1976,  some  functions  which  had  been  delegated  to  field  activites  were  reab- 
sorbed.  As  a  result,  the  ILSS  tended  to  lose  significance  as  NAVAIRSYSCOM 
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management  turned  its  attention  elsewhere.   Some  elements,  particularly  PMS 
ana  ICS  design,  were  nevertheless  pursued.   However,  the  overall  system 
demonstrations  were  not  performed  or  thoroughly  evaluated.   Had  they  been 
performed,  the  need  for  MDCS  reform  and  improvement  would  have  been  evident 
much  sooner. 

At  the  direction  of  CNO,  NAVAIRSYSCOM  (AIR-4104)  instituted  the  Increased 
ALM  Availability  and  Reduced  Maintenance  Burden  Program  in  July  of  1976.   This 
program  took  advantage  of  the  potential  offered  by  the  IRRP  to  significantly 
change  the  maintenance  process  for  ALM.   The  increased  ALM  availability  pro- 
gram had  many  attributes  worthy  of  discussion  and  resulted  in  significant 
improvements  in  missile  availability  and  in  a  reduction  of  maintenance  expense. 
The  increased  ALM  availability  program  was  to  be  implemented  immediately  by  the 
PACMISTESTCEN.   The  maintenance  status  of  a  large  portion  of  the  inventory  was 
to  be  changed  based  on  existing  data.   The  TPI  requirement  was  changed  to  SIST 
requirement  for  the  majority  of  the  inventory.   This  change  in  scheduled  main- 
tenance requirements  led  to  the  capability  to  stockpile  RFI  missiles,  and 
ultimately  to  centralize  and  control  the  management  of  I-level  maintenance. 
Increased  emphasis  was  placed  on  monitoring  the  efficiency  of  the  maintenance 
system  in  terms  of  AROs .   Significant  improvements  in  AROs  were  to  be  obtained 
largely  through  improved  management  techniques.   In  add^-ion,  scheduled  main- 
tenance was  to  be  minimized  by  increasing  SIST  to  the  extent  justified  by  test 
data.   This  mandate  presupposed  a  cause  and  effect  relationship  between  mainte- 
nance and  missile  reliability,  which  ultimately  placed  demands  on  the  type  of 
data  which  was  collected  and  analyzed. 

The  increased  ALM  availability  program  was  initiated  in  July  1976  and 
implemented  within  90  days.   Initial  guidelines  for  changes  in  ALM  maintenance 
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procedures  were  issued  via  message  in  July.   The  brevity  of  the  message  and 
the  resistance  of  personnel  at  the  weapon  stations  led  to  controversy  during 
August.   Visits  were  made  to  all  three  of  the  weapon  stations  in  an  attempt  to 
resolve  both  real  and  imaginary  problems  brought  about  by  the  new  initiatives. 

The  first  real  challenge  to  the  increased  ALM  availability  program  came 
with  the  offload  of  the  USS  RANGER  on  28  August.   Program  directives  had 
specified  that  during  offload  (implying  on  board  the  carrier),  ALM  assets 
requiring  weapon  station  maintenance  were  to  be  segregated  from  RFI  missiles. 
The  SISTs  for  the  RFI  missiles  were  to  be  extended  and  marked  on  the  missile 
containers  in  terms  of  revised  MDDs .   The  people  who  were  implementing  the 
program  decided  that  it  would  be  impractical  to  establish  SISTs  for  RFI 
missiles  on  board  the  USS  RANGER,  largely  because  they  did  not  have  access  to 
the  required  MDCS  (configuration  summary  form  service  life)  data  from  FLTAC . 
Therefore,  the  decision  was  made  to  return  all  of  the  USS  RANGER  assets  to 
WPNSTA  Concord  for  segregation. 

During  a  ten  day  period  starting  on  11  September,  a  large  number  of  SPARROW 
and  SIDEWINDER  missiles  (80  percent  of  the  USS  RANGER  inventory)  were  turned 
around  and  sent  to  the  USS  CONSTELLATION  without  significant  maintenance  proc- 
essing.  Accomplishing  this  turnaround  required  use  of  the  main  missile 
processing  building  at  Concord.   Missile  containers  had  to  be  opened  to  get  at 
the  MDCS  configuration  summary  forms  which  had  been  packed  with  the  missiles. 
The  USS  RANGER  turnaround  was  considered  a  tremendous  success  because  it  rapidly 
made  a  large  number  of  assets  available  and  saved  the  Navy  an  estimated  quarter 
of  a  million  dollars  in  processing  costs.   The  USS  RANGER  turnaround  also 
taught  the  personnel  who  participated  in  it  a  lesson.   The  turnaround  could 
have  been  conducted  on  board  the  carrier  had  appropriate  data  been  available. 
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The  second  offload  to  be  sentenced  was  the  USS  KENNEDY  in  December  1976. 
Starting  in  October,  PACMISTESTCEN  personnel  requested  MDCS  data  for  the  USS 
KENNEDY  offload  from  FLTAC .   FLTAC  did  not  respond  with  any  data.   Personnel 
from  NWS  Yorktown  accomplished  the  turnaround  on  board  the  USS  KENNEDY  using 
data  extracted  from  the  weapon  station  files.   The  turnaround  was  also  a 
success  except  for  some  SHRIKE  and  WALLEYE  assets  which  were  erroneously  sen- 
tenced for  weapon  station  processing  because  it  was  not  realized  that  the 
service  lives  of  some  explosive  components  had  been  extended.   The  first  USS 
KENNEDY  turnaround  proved  that  container  markings  were  not  an  adequate  basis 
for  sentencing  missiles. 

L.   MSI  PLANS 

Missile  sentencing  aboard  carriers  for  the  period  1976  through  1985  and 
the  corresponding  MSI  plans  are  appropriate  subjects  for  this  discussion  since 
they  probably  represent  the  most  extensive  and  most  prolonged  examination  of 
MDCS  data  in  existence.   In  the  spring  of  1977,  PACMISTESTCEN  began  formali- 
zation of  MSI  procedures  with  the  publication  of  an  instruction.   The  primary 
feature  of  this  instruction  was  that  an  individual  MSI  plan  would  be  generated 
for  each  carrier.   These  plans  were  necessary  since  the  required  data  was  not 
available  and  sentencing  rules  were  too  complex  to  allow  simple  missile 
sentencing  in  carrier  magazines.   In  effect,  the  plans  pre-sentenced  carrier 
inventories  based  on  maintenance  data.   On  board  inspectors  were  there  to 
verify  the  condition  of  missiles  and  to  tag  containers.   Exceptions  were  to  be 
recorded  in  MSI  plans.   The  following  data  was  required  for  the  preparation  of 
MSI  plans: 
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1.  Carrier  inventory  and  deep  stowage  status,  which  was  obtained  from  the 
Conventional  Ammunition  Integrated  Management  System/Serial  Lot  Tracking 
System  (CAIMS/SLIT) . 

2.  Missile  test  dates  and  service  life  data,  which  was  be  obtained  from  the 
Shore  MDCS  subsystem. 

The  MSI  plans  tracked  inventories  and  predicted  the  results  of  carrier 
offloads  from  the  time  the  missiles  were  onloaded  until  they  were  offloaded, 
usually  a  period  of  a  year.   The  active  MSI  plans  combine  to  represent  a  large 
percentage  of  the  Fleet  inventory  at  any  given  time.   In  time,  MSI  plans 
became  an  effective  management  information  system,  if  not  officially  recog- 
nized as  part  of  the  NAVAIRSYSCOM  (AIR-420)  MIS. 

At  first,  MSI  plans  were  generated  by  hand.   In  1978,  however,  efforts 
were  made  toward  their  mechanization.   Automation  of  the  plans  facilitated 
periodic  update.   During  1977,  hand  written  lists  of  MDCS  data  required  for 
MSI  plans  were  submitted  to  FLTAC.   Mixed  results  were  obtained  from  these 
submittals.   Sometimes  there  was  no  response;  other  times  the  data  was  too 
late  to  be  useful.   Most  of  the  time  the  data  appeared  to  contain  too  many 
errors  to  be  of  any  value.   In  efforts  to  obtain  a  better  response  from  FLTAC, 
PACMISTESTCEN  adopted  the  practice  of  requesting  data  via  message  with  infor- 
mation copies  to  NAVAIRSYSCOM.   FLTAC  interpreted  these  messages  as  an 
aggressive  move  and  communications  broke  down  for  a  while.   A  rapprochement 
was  achieved  in  1979,  when  for  the  first  time,  the  two  organizations  began 
working  together.   A  special  file  known  as  CROSSDECK  was  set  up  under  the  ICS 
subsystem,  enabling  PACMISTESTCEN  to  enter  serial  numbers  of  assets  which 
required  MSI  data.   FLTAC  was  able  to  transfer  these  lists,  screen  MDCS  files, 
and  input  the  required  data  into  the  appropriate  ICS  file  for  retransmission 
to  PACMISTESTCEN.   This  ICS  file  worked  fairly  well  and  requests  were 
generally  completed  within  a  week. 
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For  the  first  time,  relatively  large  amounts  of  Shore  MDCS  data  were 
scrutinized  continuously.   At  first  the  data  appeared  to  be  incredibly  bad, 
especially  for  recently  loaded  assets.   However,  over  a  period  of  time  it 
became  apparent  that  at  least  the  test  dates  and  service  life  data  were  intact 
and  reasonably  accurate  and  complete.   The  major  problem  was  that  FLTAC 
required  an  incredibly  long  time  to  get  the  data  loaded  into  the  UNIVAC 
computer. 

This  long  delay  was  nominally  six  months,  but  varied  significantly.   Even 
with  the  improved  turnaround  of  the  ICS  CROSSDECK  file,  which  had  direct 
access  to  the  primary  MDCS  files,  the  user  was  deprived  of  the  last  six  months 
of  weapon  station  data.   Rather  than  admit  that  their  collection  system  was 
inadequate  and  slow,  FLTAC  had  been  feeding  PACMISTESTCEN  obsolete  data  from 
previous  maintenance  cycles  of  the  assets.   The  use  of  obsolete  data  was  not 
limited  to  MSI  plans,  and  probably  occurred  with  most  requests  for  MDCS  data. 
The  only  accurate  data  obtained  during  this  period  was  for  those  maintenance 
problems  (requests  for  data)  which  viewed  maintenance  from  a  delayed  histor- 
ical viewpoint.   With  the  development  of  SIST,  the  improved  ALM  availability 
forced  asset  maintenance  into  a  two  to  three  year  cycle. 

From  a  maintenance  management  point  of  view,  the  only  important  data  was 
that  which  pertained  to  the  current  cycle  since  it  reflected  the  maintenance 
status  of  the  current  inventory.   The  leisurely  inclusion  of  data  into  Shore 
MDCS  files  dramatically  compromised  the  picture  that  MDCS  provided  of  this 
cycle.   This  slowness  had  a  rippling  effect.   Not  only  were  users  deprived  of 
six  months  of  the  most  recent  data,  but  they  were  instead  fed  the  last  six 
months  of  the  previous  cycle.   The  problem  seems  simple,  but  these  effects 
were  not  obvious  from  isolated  requests  for  data.   Programs  such  as  MSI 
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planning  exposed  the  slowness  of  data  input.   MDCS  data  supplied  for  initial 
carrier  onloads  was  incredibly  bad.   This  data  usually  indicated  that  all 
assets  loaded  on  the  carrier,  except  those  which  were  crossdecked,  should  be 
non-RFI.   It  was  only  as  the  carrier  deployment  progressed  that  MDCS  data 
finally  improved  through  monthly  requests  for  data  updates.   By  the  time  of 
asset  offload,  the  data  was  fairly  accurate. 

The  delay  of  data  input  into  Shore  MDCS  is  probably  the  second  most  impor- 
tant failure  of  that  subsystem  during  the  last  half  of  the  1970s  and  into  the 
1980s.   The  slowness  was  important  in  its  own  right  since  it  severely  compro- 
mised the  effectiveness  of  the  subsystem.   Of  more  significance,  however,  the 
delay  was  never  officially  acknowledged.   The  inability  of  management  to  recog- 
nize the  problem  probably  contributed  more  toward  MDCS  subsystem  damage  than 
can  be  justified.   FLTAC  analysts  were  well  aware  of  the  extreme  delay  of  data 
input  to  MDCS.   FLTAC  management  tried  to  avoid  the  issue  of  the  delay  when 
possible,  and  defended  themselves  by  stating  that  they  had  done  their  job  by 
collecting  the  required  data.   If  it  was  bad  or  erroneous,  they  blamed  the 
weapon  stations  for  not  reporting  the  required  data.   If  pressed,  FLTAC  manage- 
ment stonewalled  and  would  admit  to  the  two  month  delay  between  receipt  of  MDCS 
forms  and  the  time  data  was  entered  into  UNIVAC  files.   This  generalization 
was  consistently  caveated  with  a  further  rationalization  that  data  input  had 
been  currently  curtailed  due  to  the  lack  of  funding.   As  such,  data  input 
became  driven  by  FLTAC/NAVAIRSYSCOM  (AIR-420)  controversies  over  funding.   The 
nominal  two  month  delay  in  data  input  at  FLTAC  implied  that  the  weapon  stations 
were  at  fault  in  getting  the  data  forms  to  FLTAC.   Most  users  tended  to  reject 
this  implication  since  they  could  obtain  copies  of  the  collection  forms  within 
a  week  of  their  generation  at  the  weapon  station. 
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As  stated  earlier,  users  of  Shore  MDCS  data  were  slow  to  discover  the 
extreme  delay  in  loading  the  data  into  UNIVAC  files  and  its  impact  on  any 
resultant  analysis.   Isolated  requests  for  data  usually  resulted  in  no  data 
or  what  appeared  to  be  bad  data.   By  the  time  the  delay  was  discovered  and  its 
impact  recognized  at  PACMISTESTCEN,  efforts  were  well  underway  toward 
developing  maintenance  management  subsystems  which  would  project  and  predict 
maintenance  pipeline  processes  years  in  advance.   The  development  of  SIST  had 
given  the  weapon  station  the  capability  to  stockpile  missiles,  and  therefore 
the  capability  to  schedule  weapon  station  workloads.   This,  in  turn,  led  to 
the  capability  to  centralize  maintenance  management.   On  the  other  hand,  CNO's 
difficult  AROs  necessitated  increased  maintenance  management  to  achieve  the 
required  objectives.   The  development  of  these  maintenance  management  subsys- 
tems centers  around  another  subsystem  within  the  ILSS  known  as  Workload 
Coordination  (WLC) .   WLC  was  defined  as  a  subsystem  of  the  ILSS  Planning, 
Programming,  and  Budgeting  System  (PPBS),  a  distinct  system  from  the 
NAVAIRSYSCOM  (AIR-4104)  MIS. 

M.   MAINTENANCE  MANAGEMENT 

The  ILSS  allowed  NAVAIR  to  delegate  the  WLC  subsystem  function  to 
PACMISTESTCEN  in  the  fall  of  1975.   One  of  the  primary  functions  of  WLC  is  to 
generate  a  Workload  Execution  Plan  (WEP) ,  which  projects  the  ALM  commodity 
workload  requirements  for  I-  and  D-level  maintenance  at  specific  activities 
for  the  next  five  quarters.   Originally,  the  WEP  was  generated  by  hand  and 
required  extensive  liaison  with  Fleet  and  shore  based  activities  to  determine 
existing  and  anticipated  Fleet  loadout  requirements  and  weapon  station 
inventories.   In  1975  and  1976,  the  WEP  was  marginally  accurate  in  predicting 
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next  quarter  workloads,  although  projections  for  ensuing  quarters  were  not 
given  much  credence. 

The  improved  ALM  availability  program  placed  significant  pressure  on 
increasing  the  accuracy  of  WEP  projections.   Initially,  however,  the  initi- 
atives of  the  program,  particularly  the  automatic  SIST  extension  and  on-site 
inventory  of  unserviceable  assets  at  weapon  stations,  made  the  WEP  projections 
highly  inaccurate.   The  competition  between  the  WEP  and  the  improved  ALM 
availability  program  created  animosities  within  particular  factions  at  PAC- 
MISTESTCEN  for  control  of  the  maintenance  management  of  ALMs .   By  the  spring 
1977,  personnel  involved  with  MSI  plans  realized  that  the  plans  could  be  com- 
bined to  form  a  more  effective  basis  for  WEP  projections.   At  the  time,  WEP 
projections  treated  all  offloaded  assets  as  non-RFI  while  MSI  projections 
separated  assets  as  both  non-RFI  and  RFI.   Some  of  the  RFI  assets  would  be 
crossdecked  and  not  returned  to  weapon  station  inventories. 

To  some  extent,  the  hostilities  mentioned  above  prevented  integration  of 
MSI  and  WEP  efforts  at  PACMISTESTCEN.   The  major  factor  preventing  integration 
was  that  both  MSI  plans  and  WEPs  were  generated  by  hand.   The  great  amount  of 
effort,  detail,  and  need  for  constant  revision  made  the  integration  unfeasible 
at  that  time.   Nevertheless,  a  major  breakthrough  occurred  in  February  1978 
when  the  Ships  Parts  Control  Center  (SPCC)  agreed  to  start  sending  PACMISTEST- 
CEN monthly  tapes  of  CAIMS/SLIT.   With  these  tapes,  PACMISTESTCEN  began  to 
quietly  automate  MSI  plans.   One  of  the  things  these  tapes  revealed  was  that 
missile  status  at  the  time  of  carrier  onload  and  current  MDDs  were  more 
accurately  depicted  in  SLIT  than  in  equivalent  MDCS  data.   To  increase  the 
accuracy  of  the  MSI  plans,  PACMISTESTCEN  tended  to  ignore  FLTAC  MDCS  input  for 
the  early  stages  of  deployment  and  used  slightly  different  SLIT  data  instead. 
To  defend  their  position,  PACMISTESTCEN  argued  that  MDCS  data  was  incorrect. 
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In  February  1978,  SPCC  also  began  shipping  monthly  CAIMS/SLIT  tapes  to 
FLTAC  for  some  undetermined  reason.   This  tape  was  converted  into  a  UNIVAC 
file,  supposedly  so  that  FLTAC  could  verify  MDDs  listed  in  SLIT  records.   It 
is  not  known  how  much  of  the  SLIT  data  FLTAC  used.   To  conform  to  the  CNO 
mandate  not  to  maintain  duplicate  data  bases,  little  effort  has  been  expended 
toward  integrating  SLIT  and  MDCS  data.   The  integration  of  this  data  is,  of 
course,  one  of  the  fundamental  prerequisites  of  a  viable  NAVAIRSYSCOM  (AIR-420) 
MIS. 

By  the  fall  of  1978,  PACMISTESTCEN  had  completed  automation  of  MSI  plans. 
Their  execution  from  that  time  foward  became  an  increasingly  routine  matter. 
PACMISTESTCEN  informally  transferred  control  of  MSI  plans  and  they  became  a 
WLC  function.   With  this  transfer,  MSI  plans  became  the  driver  for  the  WEP. 
Once  the  MSI  plans  became  a  WLC  function,  there  was  no  longer  any  objection  to 
their  use  as  a  basis  for  the  WEP. 

At  the  same  time,  AROs  of  several  primary  assets  declined  drastically. 
NAVAIRSYSCOM  (AIR-420)  started  remedial  action  including  revision  or  redefini- 
tion of  the  ILSS  in  the  form  of  the  NAWMP,  purge  of  the  CAIMS/SLIT  data  files, 
institution  of  more  accurate  data  reporting  by  CONUS  activities,  and  finally, 
increased  emphasis  on  management  of  maintenance  processing.   As  part  of  the 
latter  effort,  NAVAIRSYSCOM  (AIR-420)  issued  tasking  to  FLTAC  to  develop  an 
automated  WEP.   This  assignment  was  an  afront  to  PACMISTESTCEN  management 
since  the  WEP  was  considered  part  of  their  WLC  subsystem.   PACMISTESTCEN 
quietly  started  automating  the  worksheets  which  comprise  the  WEP,  one  by  one. 
Efforts  at  FLTAC  to  develop  an  automated  WEP  floundered  during  1979,  1980,  and 
1981.   It  appeared   at  they  did  not  properly  understand  the  maintenance  proc- 
esses underlying  the  WEP  nor  the  data  elements  necessary  to  characterize  those 
processes . 
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In  reality,  obtaining  this  understanding  was  a  simple  matter.   The  WEP 
worksheets  were  in  fact  road  maps  and  plans  on  how  to  construct  an  automated 
WEP.   FLTAC  did  not  want  to  import  PACMISTESTCEN  technology,  but  preferred  to 
develop  a  new  system  of  their  own.   By  attempting  to  develop  a  new  system, 
FLTAC  took  a  significant  chance.   The  PACMISTESTCEN  had  carefully  tailored 
their  system  to  mirror  existing  ALM  maintenance  processes.   To  deviate  from 
the  WEP  or  its  underlying  processes  was  to  deviate  from  reality  and  introduce 
error.   One  of  FLTAC 's  fundamental  mistakes  was  to  attempt  to  drive  their 
automated  WEP  wherever  possible  with  MDCS  data.   In  this  application,  MDCS 
data  was  simply  not  pertinent;  MDCS  does  not  contain  the  data  required  to 
develop  a  viable  WEP.   In  1981,  the  FLTAC  effort  to  develop  an  automated  WEP 
was  cancelled  with  little  if  anything  accomplished.   The  WEP  had  already  been 
automated  at  PACMISTESTCEN. 

The  futile  attempt  by  FLTAC  to  develop  an  automated  WEP  pinpoints  a  third 
more  fundamental  and  philosophical  problem  with  MDCS:   the  system  probably 
contains  very  little  data  which  can  effectively  be  used  in  a  NAVAIRSYSCOM 
(AIR-420)  management  information  system.   Although  MDCS  files  contain  the 
elements  described  in  its  documentation  pamphlets,  they  are  now  obsolete. 
Fifteen  years  have  elapsed  since  MDCS  was  designed  to  reflect  a  maintenance 
system  that  was  autonomous  and  inefficient  by  today's  standards.   That  main- 
tenance system  has  not  existed  for  ten  years,  yet  there  has  been  little 
fundamental  change  in  MDCS.   The  concepts  of  decentralization  and  the  separa- 
tion and  specialization  of  data  bases  have  severely  handicapped  MDCS.   MDCS 
may  indeed  characterize  maintenance  actions  carried  on  with  significant  detail, 
but  it  does  not  reflect  the  overall  framework  of  the  process.   In  terms  of  the 
original  intent  as  described  OPNAVINST  4790.,  MDCS  must  be  considered  a 
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.ignificant  failure.   It  has  little  3M  utility  either  in  the  management  of 
material  or  the  maintenance  thereof. 

By  current  standards,  the  WEP  cannot  be  called  an  effective  management 
information  system  either.   It  is,  in  fact,  an  automated,  periodic  report  with 
no  mechanized  interactive  or  distributive  capability.   However,  the  WEP  is  one 
of  NAVAIRSYSCOM  AIR-420's  most  effective  maintenance  management  tools.   The 
success  of  the  WEP  can  be  traced  to  the  fact  that  it  indigenously  mirrored 
processes  which  its  users  wished  to  control.   Emphasis  was  placed  on  charac- 
terizing procedures,  not  data.   Users  were  free  to  select  data  from  available 
sources.   If  MDCS  had  contained  the  best  data,  it  would  have  been  selected. 
It  turned  out  that  the  CAIMS/SLIT  data  was  of  greater  utility.   Today  the  WEP 
is  a  fundamental  part  of  the  NAVAIRSYSCOM  (AIR-420)  maintenance  management 
function.   Although  the  WEP  could  be  improved  with  further  modernization,  it 
should  be  utilized  as  a  cornerstone  in  the  development  of  a  new  MMIS. 

One  final  aspect  of  the  improved  ALM  availability  of  1976  which  bears  on 
MDCS  was  the  mandate  to  "extend  SIST  to  the  extent  justified  by  data."  This 
mandate  assumed  that  there  was  a  causal  relationship  between  the  time  interval 
at  which  scheduled  maintenance  was  performed  and  the  amount  of  failures  which 
could  be  expected  in  Fleet  inventories.   This  idea  has  considerable  merit 
although  it  was  later  shown  that  failure  rates  were,  to  a  considerable  extent, 
time  independent.   The  importance  of  the  mandate  was  that  it  called  for  a  new 
type  of  analysis  or  utilization  of  data  which  the  ALM  maintenance  community 
was  ill  prepared  to  perform.   Neither  the  existing  maintenance  processes  nor 
data  systems  had  been  designed  to  evaluate  such  problems.   To  perform  these 
analyses  it  was  necessary  o  characterize  certain  aspects  of  maintenance. 
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1 .  Fleet  Exposure  of  Assets 

This  data  might  have  been  available  had  Fleet  MDCS  been  operational. 
Instead,  PACMISTESTCEN  collected  this  data  during  execution  of  MSI  plans. 

2.  Asset  Failures  During  Processing 

This  data  was  available  in  Shore  MDCS  via  ICS  after  significant  time 
delays.   It  was  often  more  effective  to  obtain  copies  of  MDCS  processing  forms 
directly  from  the  weapon  stations. 

3 .  Part  Failures  During  Depot  Repair 

This  data  may  have  become  available  in  depot  MDCS.   The  extreme  time 
delay  between  failures  in  the  Fleet  and  the  part  repair  at  the  depot  precluded 
this  step  in  analysis. 

4.  The  Cause  of  Part  Failures 

The  ALM  maintenance  process  does  not  contain  any  provision  for  true 
failure  analysis.   Weapon  Quality  Evaluation  Centers  (WQECs)  are  sometimes 
funded  on  a  missile  by  missile  basis  to  perform  such  analysis.   The  resultant 
data  is  usually  not  contained  in  any  data  base,  except  possibly,  AWCAP.   SIST 
extensions  were  finally  accomplished  for  SPARROW  and  SIDEWINDER  missiles  in 
1981  based  on  completion  of  steps  1  and  2  in  the  process  noted  above.   The 
ultimate  causes  of  failures  or  the  reasons  for  the  time  independent  failures 
were  never  determined. 

N.   DEPOT  MDCS 

Previous  discussions  have  centered  primarily  around  Shore  MDCS.   It  is 
appropriate  to  briefly  document  the  history  and  status  of  the  third  subsystem, 
depot  MDCS.   The  ILSS  recognized  the  need  for  data  subsystems  for  each  of  the 
three  levels  of  maintenance  and  had  initiated  their  development  in  1972.   The 


51 


second  revision  of  the  ILSS  Program  Master  Plan,  dated  December  1974,  also 
claimed  that  development  of  all  three  MDCS  subsystems  was  complete  and  test 
and  evaluation  would  soon  be  implemented.   As  stated  earlier,  however,  this 
test  and  evaluation  never  took  place.   It  was  also  apparent  that  the  develop- 
ment of  depot  MDCS  was  behind  its  Shore  MDCS  counterpart  to  some  extent.   The 
depot  MDCS  documentation  manual  was  being  circulated  in  draft  format  while  its 
shore  counterpart  had  been  approved. 

In  1975,  depot  level  maintenance  of  ALMs  consisted  primarily  of  repair  of 
SPARROW  (AIM-7E)  and  SHRIKE  (AGM-45)  components  at  NARF  Alameda  and  repair  of 
SIDEWINDER  (AIM-9G)  components  at  NARF  Norfolk.   Planning  was  in  progress  for 
depot  level  repair  of  emerging  missile  systems  at  various  prime  contractor 
sites : 

1.  STANDARD  ARM  (AGM-78A)  operational  (1969)  -  General  Dynamics,  Pomona. 

2.  PHOENIX  (AIM-54A)  operational  (1975)  -  Hughes  Aircraft  Company,  Tucson. 

3.  SPARROW  (AIM-7F)  operational  (1976)  -  Raytheon  Corporation,  Lowell. 

4.  HARPOON  (AGM-84)  operational  (1977)  -  McDonnell  Douglas,  St.  Louis. 

The  first  major  problem  with  the  depot  MDCS  was  that  its  implementation  was 
initially  delayed  and  sporadic  depending  on  the  missile  system  in  question.   In 
1975,  FLTAC  leased  Mohawk  terminals  and  contracted  operators  to  perform  coding 
at  NARF  Norfolk.   It  is  noteworthy  that  these  terminals  were  to  transmit  data 
directly  to  the  FLTAC  UNIVAC.   Data  was  collected  on  forms  generated  by  NARF 
Norfolk,  so  they  had  some  control  over  data  elements  and  coding.   From  all 
reports,  operations  at  NARF  Norfolk  were  fairly  successful.   They  were  super- 
seded, however,  by  a  decision  in  19  76  to  curtail  SIDEWINDER  repair  at  Norfolk 
concurrent  with  the  deployment  of  the  AIM-9H.   In  contrast  to  Norfolk,  NARF 
Alameda  resisted  attempts  to  implement  MDCS  at  their  site.   Alameda  had  devel- 
oped its  own  internal  reporting  system  and  considered  MDCS  an  unnecessary 
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imposition.   NARF  Alameda  successfully  delayed  the  battle,  arguing  that  formats 
and  coding  were  awkward  and  unusable.   The  relative  autonomy  of  NARF  Alameda 
prevented  direct  imposition  of  MDCS  reporting.   It  is  believed  that  NARF 
Alameda  did  not  consistently  begin  reporting  until  1979. 

Depot  MDCS  reporting  for  the  other  missile  systems  was  even  more  sporadic. 
During  the  period  of  1976  through  1978,  emphasis  was  placed  on  controlling  and 
centralizing  management  of  I-level  maintenance  at  weapon  stations.   Weapon 
stations  were  considered  the  vulnerable  link  and  the  area  where  the  most 
improvement  could  be  obtained  in  terms  of  the  ARO.   Accordingly,  depot  level 
maintenance  and  depot  level  reporting  were  given  less  emphasis.   It  was  not 
until  1979  that  individual  studies  of  the  AIM-54A  and  AIM-7F  systems  and 
generalized  SIST  modeling  proved  that  the  slow  turnaround  of  assets  at  depots 
had  significant  impact  on  asset  availability. 

NAVAIRSYSCOM  (AIR-420)  has  less  control  over  depot  level  repair  performed 
by  prime  contractors  than  it  does  with  the  remaining  portions  of  the  ALM  main- 
tenance system.   In  the  first  place,  prime  contractors  are  strongly  motivated 
by  NAVAIRSYSCOM  (AIR-05)  development  and  acquisition  contracts.   While  prime 
contractors  consider  depot  repair  efforts  to  be  lucrative  and  necessary,  they 
are  certainly  secondary  to  the  major  acquisition  contracts.   In  addition,  depot 
level  repair  efforts  are  often  tied  to  major  support  contracts  of  which  NAVAIR- 
SYSCOM (AIR-420)  does  not  have  full  control.   Most  prime  contractors  prefer  to 
utilize  their  own  data  systems  and  tend  to  view  MDCS  reporting  as  an  imposi- 
tion.  Experience  indicates  that  NAVAIRSYSCOM  (AIR-420)  has  had  difficulty  in 
enforcing  MDCS  reporting  requirements  on  prime  contractors  performing  depot 
level  maintenance.   Records  for  the  periods  in  which  Hughes  Aircraft  Company 
performed  AIM-54A  maintenance  are  spotty  in  MDCS.   McDonnell  Douglas  resisted 
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all  attempts  to  include  HARPOON  depot  level  repair  in  MDCS  until  1981,  at 
which  time  they  dumped  four  years  of  data  on  FLTAC.  The  result  was  a  mass  of 
unintelligible  and  unverifiable  data  which  has  never  been  sorted  out.  Appar- 
ently, SPARROW  AIM-7F  and  STANDARD  ARM  AGM-78A  data  from  Raytheon  and  General 
Dynamics  have  never  been  incorporated  in  depot  MDCS.  Although  the  utility  of 
depot  MDCS  is  an  open  question,  the  subsystem  has  never  been  fully  implemented 
and  does  not  contain  the  data  that  it  was  designed  to  collect. 

0.   SOURCE  DATA  AUTOMATION 

The  discussion  now  turns  to  the  history  of  the  Source  Data  Automation 
Network  (SDAN)  and  its  predecessor,  the  SPARROW  Information  Network  (SIN). 
SDAN  was  a  FLTAC  effort  to  improve  one  of  the  major  problems  associated  with 
Shore  MDCS:   the  extreme  delay  in  incorporating  data  in  MDCS  files.   The 
failure  of  SDAN  or  at  least  the  extreme  delay  (nine  years)  in  making  SDAN 
operational  has  in  effect  precipitated  the  current  controversy  over  the 
utility  of  MDCS  in  NAVAIR  ALM  maintenance  management  functions. 

As  early  as  1975,  individuals  at  the  working  level  believed  that  MDCS  had 
significant  problems  and  were  voicing  their  criticism.   This  was  also  the  time 
when  advances  in  Transistor-Transistor  Logic  (TTL)  technology  had  led  to  the 
introduction  of  the  relatively  low  cost  of  minicomputers.   The  minicomputer 
provided  an  alternative  to  centralized  computer  information  systems.   Distri- 
buted networks  of  small  computers  with  interactive  capability  were  now 
feasible. 

In  the  fall  of  1976,  a  group  of  individuals  from  NAVAIR,  PACMISTESTCEN, 
and  FLTAC  proposed  that  a  new  maintenance  data  system  should  be  developed  in 
conjunction  with  the  scheduled  introduction  of  the  SPARROW  AIM-7F  into  the 
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Fleet  in  the  spring  of  1977.   The  group  was  funded  and  had  the  support  of  the 
SPARROW  Program  Manager,  Air  (PMA) .   Since  the  system  was  funded  by  the  PMA, 
it  was  designed  to  support  a  single  missile  system--the  SPARROW.   As  mentioned 
previously,  the  new  maintenance  data  system  was  to  be  called  the  SIN.   For  its 
time,  SIN  included  many  innovative  features,  including: 

1.  Reassessment  of  MDCS  data  elements  to  assure  their  utility  in  management 
and  logistics  functions.   Unofficial  estimates  indicated  that  at  least 
fifty  percent  of  MDCS  data  elements  could  be  eliminated  with  no 
significant  loss  of  function. 

2.  Absorption  of  vital  data  elements  from  other  data  systems  such  as  SLIT. 

3.  Redefinition  of  data  elements  to  reflect  maintenance  processes. 

4.  Development  of  a  missile  traveler  based  on  punched  card  technology  to 
simplify  data  collection  processes. 

5.  Implementation  of  a  distributed  network  of  computers  throughout  the  ALM 
maintenance  community  to  speed  data  input  to  a  central  data  agency; 
allow  direct  user  access  to  central  data  agency  files;  allow  development 
of  user  files  and  processing  to  specific  site  requirements. 

6.  Allow  interactive  communication  between  all  members  of  the  network. 

In  their  zeal  to  obtain  acceptance  of  their  program,  the  advocates  of  SIN 
were  quick  to  cite  the  inadequacies  of  MDCS.   NAVAIRSYSCOM  (AIR-4104)  inter- 
preted these  actions  as  a  direct  attack  on  its  management  policies,  its  data 
systems,  and  its  supporters  throughout  the  ALM  community.   NAVAIRSYSCOM 
(AIR-4104)  did  not  like  the  attack  initiated  by  the  advocates  of  SIN,  but  there 
was  a  more  fundamental  problem.   NAVAIRSYSCOM  (AIR-4104)  required  a  single  data 
system  controlled  by  its  delegates  to  encompass  all  ALM  assets.   A  proliferation 
of  data  systems  acquired,  and  perhaps  controlled  by  political  advisaries  such 
as  the  PMAs  could  not  be  tolerated.   While  SIN  had  significant  technical  merit, 
it  had  to  be  destroyed  for  political  reasons. 

The  major  battle  over  SIN  took  place  at  FLTAC  in  the  fall  of  1977.   The 
FLTAC  advocates  of  SIN  were  judged  to  be  insubordinate  due  to  their  continued 
support  of  the  program  and  were  transferred  to  positions  having  nothing  to  do 
with  ALM  maintenance.   Simultaneously,  NAVAIRSYSCOM  (AIR-4104)  supporters  at 
FLTAC  were  given  charge  of  an  improved  MDCS  system  which  was  to  incorporate 
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many  of  the  features  of  SIN.   In  the  fall  of  1978,  FLTAC  circulated  a  draft 
specification  of  the  improved  MDCS  system  to  activities  within  the  ALM  mainte- 
nance community  for  review  and  comment.   PACMISTESTCEN' s  primary  reservations 
at  the  time  [Ref.  11]  were: 

1.  Review  and  modification  of  MDCS  data  elements  had  been  eliminated; 

2.  It  was  unclear  that  users  would  have  direct  access  to  central  data  files; 

3.  In  particular,  the  equipment  to  be  installed  at  PACMISTESTCEN  appeared 
to  have  little  or  no  data  processing  capability. 

In  a  strange  turn  of  events,  FLTAC  requested  that  PACMISTESTCEN  personnel 
assigned  to  NAVAIR-05  responsibility  review  the  document.   NAVAIRSYSCOM 
(AIR-04)  representatives  were  not  directly  consulted.   As  a  result,  PACMIS- 
TESTCEN' s  concern  was  never  directly  conveyed  to  its  NAVAIRSYSCOM  (AIR-420) 
sponsor.   On  the  other  hand,  the  PACMISTESTCEN  NAVAIR-05  representatives 
believed  that  their  desires  were  being  listened  to. 

In  1979,  FLTAC  initiated  prototype  testing  of  a  network  by  installing 
PRIME  computers  at  Corona  (a  PRIME  750)  and  at  the  Fallbrook  Annex  (a  PRIME 
450).   Efforts  were  restricted  to  the  transmittal  of  MDCS  data  of  SPARROW 
missiles  processed  at  Fallbrook  to  FLTAC  Corona.   This  prototype  testing 
encountered  significant  problems.   Initially,  there  were  problems  in  training 
personnel  to  operate  the  terminals.   Secondary  problems  occurred  with  the 
definition  of  data  elements  and  the  reliability  of  validation  routines  and 
dictionaries.   Hard  copy  forms  remained  as  the  the  primary  mode  of  MDCS  data 
collection. 

In  1981  and  1982,  FLTAC  expanded  the  network  by  installing  PRIME  450 
computers  at  WPNSTAs  Concord  and  Yorktown.   In  addition,  efforts  were  made  to 
expand  data  collection  to  cover  processing  of  SIDEWINDER  and  later,  HARPOON 
missiles.   The  same  problems  which  had  occurred  at  Fallbrook  also  occurred  at 
Concord  and  Yorktown.   In  addition,  however,  discrepancies  started  appearing 
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between  data  which  had  been  obtained  through  processing  the  collection  forms 
at  FLTAC  and  that  which  had  been  transmitted  via  the  PRIME  network.   Errors 
were  not  consistent  since  the  validation  procedures  were  not  perfect.   The 
increased  amount  of  data  flowing  into  FLTAC  taxed  the  PRIME  750  storage  capa- 
bility.  Rather  than  having  a  stand  alone  capability,  the  PRIME  750  became  the 
front  end  processor  for  the  UNIVAC  1108.   Differences  in  the  PRIME  and  UNIVAC 
operations  systems  created  problems  with  data  processing  software  and  data 
file  structures. 

In  1982,  FLTAC  changed  the  name  of  the  network  from  the  Improved  MDCS  Sys- 
tem to  SDAN  and  indicated  that  it  was  a  component  of  MDCS  primarily  intended 
to  eliminate  the  extensive  time  lag  involved  in  processing  input  data.   MDCS 
users,  particularly  at  PACMISTESTCEN,  felt  they  had  been  betrayed.   Although 
FLTAC  was  finally  admitting  to  one  of  the  primary  faults  of  MDCS,  it  was  still 
not  being  eliminated.   Due  to  the  interface  problems,  data  was  only  being  trans 
f erred  from  the  PRIME  to  the  UNIVAC  in  the  form  of  batch  processing  at  lengthy 
intervals  of  time.   To  users  who  interfaced  with  the  UNIVAC  data,  input  appear- 
ed as  slow  as  ever.   In  addition,  SDAN  had  become  a  data  collection  mechanism 
to  a  data  system  which  no  longer  had  any  credibility.   FLTAC  had  stripped  all 
of  the  data  reform  and  interactive  capability  from  the  network. 

In  1983,  relationships  between  FLTAC  and  PACMISTESTCEN  took  an  additional 
turn  for  the  worse.   When  pressed  about  plans  to  expand  the  network,  FLTAC 
representatives  refused  to  admit  that  there  had  ever  been  plans  to  include 
PACMISTESTCEN  in  the  network,  and  had  no  plans  for  installing  a  computer  at 
PACMISTESTCEN  in  the  future.   PACMISTESTCEN  was  to  be  restricted  from  any 
direct  access  to  data  files  and  would  be  allowed  only  the  preprocessed  reports 
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from  FLTAC.   Such  a  situation  was  unacceptable  to  any  individual  at  PACMISTEST- 
CEN  who  felt  his  function  required  access  to  maintenance  data. 

According  to  the  NAWMP,  as  of  February  1985,  I -level  reporting  of  SPARROW, 
SIDEWINDER,  and  HARPOON  maintenance  is  performed  via  SDAN,  with  plans  for  add- 
ing the  remainder  of  the  air-launched  missiles  and  expanding  the  capability  to 
include  depot  level  reporting.   The  majority  of  MDCS  reporting  is  still  done 
using  forms  originated  in  1975  (and  subsequently  revised).   In  the  fall  of 
1984,  NAVAIRSYSCOM  (AIR-420)  requested  evaluations  of  SDAN  as  a  means  of 
assessing  of  the  viability  of  MDCS.   In  October  1984,  NAVAIRSYSCOM  (AIR-420) 
drastically  curtailed  funding  for  the  operation  of  MDCS  and  has  tasked  both 
PACMISTESTCEN  and  FLTAC  to  initiate  remedial  actions  toward  development  of  a 
new  or  redesigned  MDCS. 
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V.   CONCEPTUAL  MMIS  CHARACTERISTICS 

This  section  presents  material  of  a  conceptual  nature  concerning  the 
characteristics  required  for  a  new  MMIS.   The  section  is  divided  into  two 
subsections.   The  first  describes  technology  transfer  principles  which  should 
be  applied  in  the  development  of  a  new  information  system.   These  principles, 
although  philosophical  in  nature,  are  considered  more  fundamental  to  the 
successful  development  of  a  new  system  than  technical  requirements.   The 
second  section  lists  conceptual  technical  requirements  for  the  new  system. 

A.   TECHNOLOGY  TRANSFER  PRINCIPLES 

Technology  transfer  has  emerged  as  a  discipline  to  evaluate  and  improve 
the  flow  of  information  between  a  variety  of  entities,  including  individuals, 
organizations,  systems,  and  perhaps  machines.   The  application  of  this  discip- 
line to  information  systems  is  especially  appropriate  since  they  are  contructed, 
or  require  the  integration,  of  all  of  the  entities  noted  above.   The  flow  of 
information  is  a  critical  factor  not  only  in  the  information  system  itself,  but 
in  its  conception,  design,  acquisition,  evaluation,  and  operation.   Although 
the  principles  of  technology  transfer  may  be  considered  philosophical  in 
nature,  they  are  perhaps  more  fundamental  to  the  development  of  a  new  system 
than  any  of  its  physical  or  technical  attributes.   Failure  to  consider  the 
principles  of  technology  transfer  could  easily  result  in  a  disaster  at  some 
stage  in  the  information  system's  life  cycle. 

Technology  transfer  is  a  topic  directly  related  to  the  development  of  a 
new  MIS.   Most  of  us  think  of  technology  transfer  as  the  flow  of  our  newly 
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g  '.erated  ideas,  information,  and  methodologies  to  someone  who  can  or  will  put 
them  to  use.    bvic  sly,  this  is  directly  applicable  to  the  MDCS,  and  therefore 
the  MIS.   Neither  of  these  systems  are  functional  due  to  the  specific  lack  of 
information  transfer.   Based  on  this  deficiency  alone,  the  system  should  be 
foresaken.   A  closer  look  at  the  basic  tenets  of  technology  transfer  provides 
some  guidelines  by  which  to  design  a  new  MIS. 

Within  the  air-launched  missile  logistics  support  system,  there  has  been  a 
mdency  to  inte  oret  inform   on  transfer  as  instructions,  documentation,  and 
structured  repc   s.   The  NA\v    s  an  ex   >le.   Tech:  ology    insfer    wever, 
occurs  only  when  people  work.   Unless  there  is  evidence  of  people's   ork  output, 
there  is  no  way  to  measure  how  much  technology  or  information  has  transferred. 
While  written  reports  and  documentation  are  necessary,  and  in  some  cases  vital 
to  the  success  of  new  technology,  they  are  certainly  not  the  yardstick  of  tech- 
nology transfer.   Most  likely,  management  personnel  accepted  this  interpretation 
because  documenting  and  disseminating  information  were  thought  of  as  efficient 
procedures  for  transferring  information. 

As  developed  by  Professors  J.W.  Creighton  and  J. A.  Jolly  of  the  Naval 
Postgraduate  School,  technology  transfer  is  defined  as  a  "purposive,  conscious 
effort  to  move  technical  devices,  materials,  methods,  and/or  information  from 
the  point  of  discovery  or  development  to  new  users"  [Ref.  12].   Thus,  the 
result  of  technology  transfer  may  be  the  user's  acceptance  of  a  common  prac- 
tice, or  it  may  be  a  different  application  of  a  technique  designed  originally 
for  another  use.   Two  things  must  be  apparent  for  transfer  to  take  place. 
First,  the  user  must  have  a  clear  knowledge  of  the  practice  or  application 
required.   Because  communication  or  linkage  between  the  user  and  the  developer 
is  not  always  close  or  effective,  the  urge  is  strong  for  the  developer  to  do 
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what  he/she  wants  rather  than  what  the  user  requires.   Since  the  MDCS  was 
designed  by  FLTAC,  many  of  its  features  do  not  serve  its  NAVAIRSYSCOM  users. 
As  with  most  innovations,  the  design  of  the  system  was  an  evolutionary  proc- 
ess, including  several  system  changes  over  a  long  period  of  time.   For  example, 
when  a  new  missile  entered  the  maintenance  pipeline,  the  system  was  modified 
to  incorporate  its  data.   Soon,  immense  quantities  of  data  were  being  col- 
lected but  very  little  was  being  utilized.   There  was,  and  still  is,  very 
little  control  over  the  design  of  MDCS  reporting  elements. 

Secondly,  the  design  of  an  innovation  must  demonstrate  that  the  capability 
of  the  system  actually  offers  substantial  advantages  to  the  business.   Thus, 
simply  disseminating  information  is  not  enough  for  technology  transfer  to  take 
place;  the  information  must  offer  rewards  for  its  use.  Information  will  only 
be  sought  to  the  extent  that  it  is  useful,  and  utilized  to  the  extent  that  its 
value  exceeds  the  cost  of  obtaining  it.   The  manager  values  the  information 
when  it  assists  in  decision  making,  otherwise  the  information  has  no  value. 
Since  there  is  a  perpetual  queue  of  information  waiting  to  be  assimilated 
outside  of  our  minds,  a  transfer  mechanism  which  recognizes  the  limitations 
and  necessity  of  data  dissemination  must  continually  be  defined.   In  other 
words,  the  source  data  for  an  innovation  must  fill  the  user's  requirements  in 
order  for  it  to  serve  as  information  for  a  problem  solution. 

In  their  studies  of  the  technology  transfer  process,  Creighton  and  Jolly 
developed  what  they  call  "The  Linker  Model,"  which  identifies  a  list  of  neces- 
sary factors  for  the  movement  of  technology  or  information  from  a  source  to  a 
user.   The  linker  is  the  individual  or  organization  which  links  the  source  and 
user  organizations;  this  is  probably  the  most  important  factor  in  the  transfer 
of  technology.   Linkers  mediate  between  the  user  and  developer  organizations 
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and  attempt  to  connect  the  user's  requirements  with  the  developer's  output. 
The  concept  of  the  link:r  essentially  enforces  the  idea  that  good  communi- 
cations are  highly  important  to  successful  technological  innovation. 

The  linker's  importance  cannot  be  overemphasized.   The  lack  of  a  linker 
during  the  initial  development  phases  of  the  MDCS  has  certainly  contributed  to 
the  system's  collapse.   The  various  modules  of  the  system,  which  were  intended 
to  reflect  the  maintenance  pipeline,  were  all  designed  and  supported  by  differ- 
ent units  within  FLTAC.   These  units  were  fairly  autonomous  in  their  operation, 
and  consequently  the  modules  evolved  to  the  point  where  one  could  not  communi- 
cate with  the  other.   For  example,  if  you  wanted  the  complete  maintenance 
history  of  a  given  missile,  you  would  have  to  request  data  from  each  FLTAC 
unit.   FLTAC  would  then  trace  back  through  the  system  to  form  an  integrated 
missile  history.   This,  of  course,  was  time-consuming  and  expensive. 

Although  the  job  of  the  linker  is  by  no  means  an  easy  one,  bypassing  it  is 
an  assurance  that  the  innovation  will  fail.   By  not  employing  a  linker  while 
developing  MDCS,  FLTAC  generated  a  system  to  fit  their  needs  and  desires, 
rather  than  those  of  the  maintenance  managers  who  used  the  information.   In 
developing  a  new  MMIS  and  MIS,  the  system  should  be  designed  using  the  fol- 
lowing elements  of  the  technology  transfer  linker  model: 

1 .    Selection  Of  Project 

This  factor  refers  to  the  selection  process  of  an  innovation.   In  the 
case  of  MDCS,  experience  has  shown  that  the  basic  reason  for  the  user's  inabil- 
ity to  work  with  the  data  is  because  the  selection  process  was  done  by  others 
trying  to  perceive  what  the  user  needed  rather  than  he  wanted.   In  other  words, 
the  research  for  the  project  has  come  before  the  client's  needs.   In  an  optimal 
state,  however,  there  should  be  a  two  way  flow  of  in   rmation  to  both  parties. 
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2.  Information  Documentation 

This  element  defines  the  format,  language,  and  complexity  of  an 
innovation's  documentation.   The  format  and  language  must  be  of  a  level  where 
it  is  understandable  by  the  user.   One  cannot  utilize  information  that  he 
cannot  interpret. 

3.  Information  Distribution 

Technology  must  flow  from  the  source  to  the  user  in  order  to  find 
application.   The  new  MIS  would  depend  on  the  number  of  entries  and  sophisti- 
cation of  computer  technology.   The  success  of  information  distribution  can  be 
measured  when  people  with  problems  can  reach  people  with  potential  solutions. 
As  noted  previously,  relations  between  NAVAIRSYSCOM  user  activities  and  FLTAC 
leave  a  lot  to  be  desired. 

4.  Technical  Credibility 

Credibility  is  an  assessment  of  the  information's  reliability  as 
perceived  by  the  user.   Since  many  users  have  trouble  differentiating  the 
source  of  information  from  the  channel  through  which  it  flows,  the  user  must 
carefully  analyze  the  two  elements  before  taking  action.   How  the  potential 
user  perceives  the  information  is  crucial  to  the  adoption  or  use  of  the 
technology.   With  MDCS,  the  data  is  viewed  as  faulty  information  owned  by 
FLTAC  rather  than  NAVAIRSYSCOM  or  weapon  stations. 

5 .  The  Linker 

As  noted  earlier,  the  linker  is  the  key  factor  in  technology  trans- 
fer. Linkers  are  not  necessarily  superior  technical  people,  but  are  instead 
the  sources  of  knowledge. 

6.  Formal  Organization 

This  element  defines  the  formal  organization  of  the  information  user, 
and  his/her  perception  of  his/her  position  within  the  organization.   The 
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attitudes  of  these  individuals  often  describe  the  overall  character  of  the 
organization.   However,  the  design  of  an  organization  should  also  be  consid- 
ered when  developing  new  innovations.   For  example,  the  Navy  comprises  a 
matrix  of  organizations,  many  of  which  need  to  be  considered  in  order  for 
technology  to  be  adopted. 

7 .  Individual  Capacity 

Capacity  refers  a  new  user's  potential  to  make  use  of  new  skills  and 
information.   This  is  an  especially  relevant  factor  when  considering  computer 
systems  such  as  MDCS,  which  may  or  may  not  require  the  addition  of  new  skills. 
When  designing  a  new  MMIS,  a  great  deal  of  thought  should  be  applied  to  whether 
or  not  weapon  station  technicians  should  input  data. 

8.  Reward/ Penalty 

The  way  in  which  a  user  observes  the  rewards  (or  lack  of)  affects  con- 
siderably his/her  own  creativity  and  the  adoption  of  new  innovations.   Extrin- 
sic rewards,  such  as  good  working  conditions  and  a  healthy  salary,  are  obvious 
to  most  of  the  working  community.   Nevertheless,  intrinsic  rewards,  such  as 
intellectual  stimulation  and  recognition  among  peers,  are  considerably  more 
effective  toward  motivating  people  to  be  creative  and  efficient.   For  the  MDCS 
user,  one  must  question  whether  there  is  a  reward  in  using  the  information. 
Is  the  user  recognized  for  making  decisions  based  on  the  information? 

9 .  Willingness 

This  element  refers  to  the  user's  ability  and/or  desire  to  utilize 
the  data  or  information.   Successful  adoption  of  an  idea  might  take  a  long 
period  of  time  from  the  instance  when  it  was  accepted  intellectually.   There 
are  many  reasons  for  the  delay.   Many  people  simply  resist  change  and  its 
rippling  repercussions.   With  MDCS,  the  users'  failure  to  use  the  data 
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immediately  cancels  any  transfer  of  information.   FLTAC ' s  resistance  to  upgrade 
the  system  demonstrates  their  apparent  laziness,  but  also  proves  the  effects 
of  financial  change  and  organizational  competency.   Successful  information 
transfer  is  contingent  upon  all  of  these  elements.   Forfeiting  any  one  element 
detracts  from  the  effectiveness  of  technology  transfer. 

The  MDCS  should  serve  as  the  linking  mechanism  between  the  source  of 
maintenance  actions  and  the  manager  of  the  maintenance  system.   Rather  than 
operating  as  a  series  of  complex  communication  channels,  the  system  should 
involve  those  performing  maintenance  with  those  managing  maintenance.   Linking 
the  two  sides  is  the  vital  element.   When  the  user  of  an  information  system 
can  be  termed  at  the  interface  point  between  information  output  and  need,  the 
system  is  called  a  linker  of  source  and  user. 

B.   TECHNICAL  REQUIREMENTS  AND  SYSTEM  OPERATION 

Although  there  are  many  conceptual  models  that  can  be  developed  for  new 
MMIS,  during  this  study  the  author  developed  a  MMIS  conceptual  model  which  is 
presented  in  the  following  paragraphs.   The  MMIS  should  have  the  following 
technical  requirements: 

1.  The  system  must  be  controllable  and  auditable. 

2.  The  system  must  have  integrity. 

3.  The  system  should  be  economical  to  operate. 

4.  The  system  must  be  user  friendly. 

5.  Data  must  be  collected  on-line  as  missile  maintenance  status  changes. 

6.  Inquiries  must  be  answered  with  up  to  the  minute  information. 

7.  The  system  must  interface  all  information  users  with  suppliers  of  data. 

8.  Missile  quality  assurance  and  input  data  quality  assurance  must  be  linked, 

9.  The  system  must  be  fail  soft. 

10.  Special  skills  or  extensive  schooling  should  not  be  required  to  run  the 
system. 

11.  User  programming  should  be  optional. 

The  new  MMIS  would  be  a  distributed  system  with  a  central  data  base  con- 
taining a  Data  Base  Management  System  (DBMS)  and  a  Decision  Support  System 
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host  computer  data  files.   This  process  would  create  the  initial  file  for  that 
particular  missile  and  would  establish  its  present  configuration  and  condition. 

2.  Comparison  of  Data  Files 

Travel  packages  for  missiles  returned  to  weapon  stations  would  be 
removed  and  compared  with  the  data  files  from  the  host  computer  to  insure  data 
consistency.   Any  discrepancies  would  be  cleared  before  maintenance  actions 
are  performed. 

3.  Verification  of  Data 

After  determining  that  the  travel  package  is  correct,  the  missile 
would  proceed  through  the  maintenance  process  in  accordance  with  the  Indus- 
trial Processing  Guide  (IPG).   The  travel  package  would  be  updated  by  the 
missile  maintenance  personnel  as  maintenance  actions  are  performed.   At  each 
quality  assurance  point,  the  quality  assurance  inspector  verifies  that  the 
maintenance  had  been  properly  performed,  verifies  data  entries,  and  updates 
host  computer  files.   The  host  would  be  updated  on  a  real-time  basis.   Each 
time  data  is  entered,  the  host  computer  checks  all  data  elements  for  validity, 
and  records  the  quality  assurance  inspector's  identification  for  auditability . 
This  process  would  assure  correctness  of  data  entered  into  the  host  computer. 

4.  Depot  Rework  Procedures 

When  a  missile  section  is  sentenced  for  depot  rework,  the  appropriate 
data  form  is  removed  from  the  travel  package,  updated,  entered  into  the 
computer,  and  forwarded  with  the  section  to  the  depot  where  the  same  processes 
are  performed  by  depot  maintenance  personnel. 

5 .  Hard  Copies  of  Maintenance  Data 

If  a  travel  package  is  lost,  a  new  one  can  be  generated  by  the  host 
through  inquiry  made  by  the  DPS.   When  travel  packages  are  filled  to  the  extent 
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that  no  more  data  can  be  recor   i,  a  new  serialized  package  is  generated  by 
the  DPS  and  the  old  travel  package  is  forwarded  for  microfilming  and  archive 
storage.   This  process  provides  hard  copy  backup  to  the  system. 

6.  Data  Entry 

Data  entry  could  either  be  by  a  centralized  data  terminal  within  the 
maintenance  facility  or  by  optical  character  reading  devices  at  centralized 
locations  within  the  maintenance  facility. 

7 .  Missile  Deployment  History 

A  missile's  deployment  history  would  be  contained  on  a  form  within 
the  travel  package.   O-level  maintenance  personnel  would  complete  the  form 
during  deployment,  but  the  data  would  not  be  entered  into  the  computer  until 
the  missile  returned  to  the  weapon  station.   MSI  teams  would  insure  that  forms 
are  filled  out  for  the  missiles  utilized  in  Fleet  deployments. 

Use  of  the  travel  package  described  above  is  merely  an  innovation  on  the 
missile  logbook  and  the  configuration  summary  forms  that  have  been  used  for 
years.   The  new  travel  package  system  offers  several  advantages.   The  travel 
package  would  move  with  the  missile.   All  the  redundant  data  would  be 
pre-printed.   The  maintenance  personnel  would  only  check  off  or  add  changes. 
The  leave  package  broadens  the  scope  of  quality  assurance  to  include  data 
entry.   Entry  times  and  dates  would  be  recorded  by  the  computer  during  data 
entry.   The  travel  package  could  be  designed  to  follow  the  IPG  and  would  be 
compared  against  its  standards.   There  would  be  one  set  of  forms,  both  for 
recording  and  accessing  data  by  both  Fleet  and  shore  facilities. 

C.   MMIS  CONCEPTUAL  ISSUES 

This  concept  contains  a  litany  of  issues  that  might  suggest  that  the 
travel  package  and  distributed  system  concepts  are  inadequate  in  meeting 
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requirements;  that  they  are  too  complex,  too  difficult  to  manage,  and  too 
subject  to  risk  and  failure.   On  the  contrary,  the  advantages  outweigh  the 
disadvantages.   A  distributed  system  is  more  robust.   It  would  not  be 
dependent  on  a  single  processor,  a  single  manager,  or  organization.   The 
system  is  more  natural.   Local  functions  are  handled  locally,  rather  than 
transferring  great  amounts  of  work  to  a  central  site  with  the  consequent  loss 
of  local  ownership  and  control.   The  distributed  system  links  users  of  the 
information  with  the  inputers  of  the  data,  provides  for  quality  assurance  of 
the  data,  hard  copy  backup,  continually  crosschecks  new  input  with  previous 
input,  instantly  updates  maintenance  actions  and  maintenance  status,  and 
allows  for  exception  reporting  to  name  a  few  advantages.   The  disadvantages 
include  greater  design  sophistication  and  an  unforgiving  pressure  on  the  local 
environment  for  reporting  accuracy  which  could  create  problems  in  terms  of 
project  management.   The  distributed  system  will  require  higher  levels  of  user 
skills  and  greater  attention  paid  to  planning  for  both  data  collection,  form 
design,  data  input  devices,  DPS  capability,  the  people  involved,  and  their 
organization. 

D.   STANDARDS  OF  PERFORMANCE 

Standards  of  performance  enable  management  to  control  the  production  proc- 
ess.  Distributed  networks  and  travelers  mirror  the  maintenance  processes,  and 
can  play  an  important  role  in  gathering  and  comparing  actual  performance  data 
with  established  standards  and  reporting  discrepancies  for  management  by 
exception.   As  presently  constituted,  the  MDCS  does  not  have  any  programmed 
standards  or  mechanism  to  make  performance  comparisons  except  by  manual  means. 
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In  recent  years,  NAVAIRSYSCOM  (AIR-420)  has  developed  standards  for  the  pro- 
duction process.   These  industrial  engineering  studies,  referred  to  earlier  as 
IPGs,  measure  times  required  to  perform  the  maintenance  processes  at  the  wea- 
pon stations.   However,  these  standards  are  not  programmed  into  the  MDCS  or 
its  resultant  information  systems.   Therefore,  the  managers  must  make  their 
own  decisions  concerning  what  is  or  is  not  a  maintenance  problem.   For  example, 
none  of  the  test  equipment  has  established  standards  for  nominal  failure  rates 
nor  has  there  been  any  way  of  comparing  maintenance  actions  or  missile  failure 
rates  between  different  weapon  stations. 

In  1981,  PACMISTESTCEN  commissioned  a  study  to  establish  and  analyze 
failure  and  rejection  rates  of  SPARROW  missiles  as  a  function  of  testing  on 
AN/DPM-21  test  sets.   The  analysis  contained  5811  individual  SPARROW  test 
records.   These  test  records  were  extracted  from  MDCS  files  on  magnetic  tapes 
provided  by  FLTAC.   With  a  sample  of   :is  magnitude,  the  objects  of  the  study 
should  have  been  met  and  some  nominal  standards  developed  for  the  AN/DPM-21 
SPARROW  missile  rejection  rates.   However,  due  to  MDCS  data  inconsistencies, 
missing  data  elements,  erroneous  source  coding,  bad  operation  codes,  and  non- 
standardized  reporting  practices,  the  study  was  not  entirely  successful  in 
establishing  failure  rates  of  the  different  tests  sets  to  determine  if  there 
was  any  kind  of  standardization. 

A  critical  factor  in  the  maintenance  process  is  Mean  Logistics  Downtime 
(MLDT) .   This  is  the  time  the  missile  remains  in  the  maintenance  pipeline 
while  waiting  for  a  repair  action  to  take  place.   MLDT  seriously  impacts  asset 
readiness.   At  present,  the  only  way  MLDT  can  be  determined  is  to  manually 
track  missiles  through  the  maintenance  process. 
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Figure  5  is  an  AUR/section  flow  diagram  for  the  maintenance  of  an 
air-launched  missile.   The  complexity  of  the  network  makes  computerized 
standards  extremely  valuable  in  the  management  of  the  maintenance  process. 
Use  of  the  computer  is  the  only  feasible  way  of  calculating  and  measuring 
performance  of  the  maintenance  system.   Standards  should  be  developed  to 
measure  and  control  the  performance  of  the  maintenance  pipeline,  and  these 
standards  should  be  programmed  into  any  future  MDCS. 
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VI.   AVAILABLE  TECHNOLOGY 

A  revolution  is  underway.   Most  Americans  are  already  well  aware  of  the 
gee-whiz  gadgetry  that  is  emerging  in  rapidly  accelerating  bursts  from  the 
world's  high  technology  laboratories.   But  most  of  us  perceive  only  dimly 
how  pervasive  and  profound  the  changes  of  the  next  twenty  years  will  be.   We 
are  at  the  dawn  of  the  era  of  the  smart  machine,  an  "information  age"  that 
will  change  forever  the  way  an  entire  nation  works,  plays,  travels  and  even 
thinks.   Just  as  the  industrial  revolution  dramatically  expanded  the  strength 
of  man's  muscles  and  the  reach  of  his  hand,  so  the  smart  machine  revolution 
will  magnify  the  power  of  his  brain. 

Newsweek,  June  30,  1980 


A.   EFFECTS  OF  TECHNOLOGY  ON  MANAGEMENT 

As  the  role  of  computers  in  organizations  has  matured,  supporting  the 
needs  of  the  manager  has  become  an  increasingly  important  function.   In  cer- 
tain fields  such  as  maintenance  management,  the  requirements  of  the  job  demand 
the  efficient  use  of  the  computer.   But  if  information  departments  are  to 
effectively  fulfill  the  needs  of  the  present  day  manager,  they  must  develop 
systems  which  managers  view  as  appropriate  to  their  needs.   Often  it  is  pre- 
ferable to  develop  a  new  system  rather  than  being  constrained  by  obsolete 
technology  and  methodology  in  the  modification  of  an  existing  system. 

Although  the  development  of  a  new  MMIS  is  a  challenging  assignment,  it  is 
a  necessary  move  for  NAVAIRSYSCOM  users.   Until  recently,  the  main  problem  for 
organizations  using  computers  was  obtaining  the  adequate  technology  for  the 
desired  application.   The  current  maintenance  management  community  requires 
the  generation  and  implementation  of  a  new  system  which  responds  faster  and  is 
broader  in  scope  than  the  current  MDCS.   Despite  FLTAC ' s  inefficiencies  in 
controlling  the  data  base  and  output  devices,  many  managers  still  view  the 
computer  as  essential  to  the  organization.   The  technology  to  improve  the 
system  is  available  now.   Developmental  problems  are  strictly  managerial. 
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Management  of  the  system  should  become  the  responsibility  of  the  user. 
For  too  long  users  have  suffered  from  FLTAC's  ineptitude.   As  the  designated 
CDCA,  FLTAC  has  attempted  to  accumulate  NAVAIRSYSCOM  maintenance  data, 
although  in  most  cases  it  is  in  a  form  that  is  unidentifiable  and  therefore 
useless  to  its  users.   The  problems  with  the  current  MDCS  must  be  approached 
from  two  angles.   First,  FLTAC  is  governed  by  NAVSEASYSCOM,  a  competing  Naval 
activity.   While  communication  is  never  a  simple  process,  dealing  with  an 
organization  which  follows  its  own  set  of  rules  can  often  times  be  chaotic. 
In  this  case,  FLTAC  is  concerned  only  with  the  operation  and  maintenance  of 
the  system  rather  than  the  value  the  data  represents  to  NAVAIRSYSCOM  logistics 
managers  and  engineers.   FLTAC ' s  basic  premise  seems  to  be,  "it's  your  data, 
we  only  collect  and  store  it." 

In  fact,  this  statement  is  true;  the  data  belongs  to  NAVAIRSYSCOM  and 
FLTAC* s  job  is  to  collect  and  store  it.   However,  NAVAIR  engineers  and  man- 
agers will  not  accept  ownership  of  the  data,  nor  will  they  attest  to  its 
credibility  so  long  as  FLTAC  continues  to  run  the  show.   This,  of  course, 
results  in  continuous  inter-organizational  conflicts,  and  more  importantly, 
a  total  lack  of  control  over  NAVAIRSYSCOM 's  information  resources. 

The  political  ramifications  of  this  problem  have  been  lengthy  and  far- 
reaching.   Over  the  past  ten  years,  there  has  been  an  increasing  effort  to 
decentralize  computer  resources,  including  the  differentiation  of  software 
from  hardware,  and  the  diffusion  of  technical  expertise.   Traditionally,  the 
computer  has  been  kept  in  a  centralized,  and  often  jealously  guarded,  organi- 
zational location.   But  with  the  advent  of  large-scale  telecommunications 
networks,  and  mini-  and  microcomputers,  the  capabilities  of  the  machine  have 
been  brought  to  the  user.   Although  this  progress  will  aid  in  the  development 
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of  alternative  infc   ation  systems,  it  does  not  alleviate  current  relations 
with  FLTAC,  who  have  resisted  the  transfer  of  authority  and  information. 
Communications  specialists  tell  us  that  when  a  competitive  threat  has  grown 
great  enough,  there  will  be  a  resulting  willingness  to  take  the  risks  inherent 
in  adopting  a  new  technology.   This  is  NAVAIRSYSCOM  (AIR-420's)  current  posi- 
tion.  FLTAC  has  created  boundaries  which  separate  users  from  their  own 
"exclusive"  data.   And  in  so  doing,  they  again  point  out  that  the  dependence 
of  others  serves  as  the  basis  of  power. 

B.   COMPUTER  DEVELOPMENTS 

As  stated  previously,  computer  technology  is  constantly  changing.   In  the 
last  several  years,  hardware  advances  have  been  incredibly  rapid.   There  have 
also  been  similar  though  less  publicized  software  improvements.   Today,  the 
generation  of  adequate  software  determines  the  speed  and  accuracy  of  computer 
base~  applications.   As  a  result,  computer  software  is  an  increasingly  more 
impoi^ant  consideration  than  computer  hardware. 

However,  both  are  necessary  considerations  when  developing  any  kind  of  com- 
puter system.   Although  the  technologic  advances  in  computer  science  have  been 
almost  immediate,  this  perpetual  frenzy  of  innovation  has  left  many  computer 
buyers  with  obsolete  systems.   The  PRIME  450  computers  presently  used  at  the 
weapon  stations  are  examples.   With  an  increasing  number  of  effective  computers 
on  the  market,  the  actual  worth  and  utility  of  the  PRIMEs  is  in  question.   In 
comparison  to  the  computers  of  today,  the  PRIME  is  outdated.   Today's  personal 
computers  can  probably  fulfill  the  majority  of  user  requirements,  and  some  can 
even  surpass  the  capability  of  the  PRIME  450s. 
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With  the  abundance  of  items  on  today's  computer  market,  it  is  easy  to  buy 
a  computer.   How  intelligently  the  computer  is  used  ultimately  depends  on 
planning,  which  in  turn  depends  on  a  clear  knowledge  of  the  business.   In 
designing  and  buying  a  new  system,  it  is  also  important  to  realize  that  the 
ubiquity  of  the  computer  demands  the  efficient  reporting  and  storage  of  data. 
Many  people  no  longer  wish  to  see  lengthy  dissertations  analyzing  raw  data. 
They'll  analyze  it  themselves.   The  use  of  computers  in  our  society  is  quickly 
reaching  the  point  where  to  remain  competitive,  you  must  use  a  computer  to  aid 
not  only  in  storing  data  but  in  making  decisions.   As  a  buyer  of  new  computer 
hardware  systems,  NAVAIRSYSCOM  (AIR-420)  must  also  remain  current  with  the 
computer  industry  in  an  effort  to  stay  abreast  of  even  further  innovations. 
For  example,  at  the  present  time,  developmental  efforts  continue  toward 
"talking"  to  computers  rather  than  typing  the  required  information.   There  has 
been  considerable  achievement  in  this  area  and  society  cannot  help  but  wonder 
when  it  will  finally  be  consummated. 

The  effects  of  this  new  technology  and  others  like  it  on  the  maintenance 
community  should  be  considered  when  purchasing  a  new  system.   Although  the 
PRIME  computers  can  still  provide  the  information  required,  they  are  much 
slower  to  work  with  than  a  modern  microcomputer.   Advances  in  the  design  of 
microprocessors  have  led  many  users  to  expect  data  to  be  processed  in  real- 
time. 

C.   SYSTEM  ALTERNATIVES 

As  an  alternative  to  a  real-time  system,  batch  processing  is  also  avail- 
able.  However,  "batching"  information  means  that  the  user  does  not  have 
access  to  the  computer's  CPU.   In  batch  mode  systems,  processing  requirements 
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are  collected  at  a  central  site,  sorted,  and  processed  as  the  computer  has 
time.   Batching  obviously  reduces  the  timeliness  of  reporting  information, 
which  in  the  case  of  MDCS,  has  been  a  determining  factor  in  estimating  the 
system's  worth.   However,  as  opposed  to  on-line  processing,  batching  is  much 
more  economical.   In  addition,  it  is  an  effective  application  when  the  delay 
caused  by  queuing  data  does  not  reduce  the  value  of  the  information.   On-line 
processing  involves  different  degrees  of  processing  speed.   For  example,  a 
system  may  combine  immediate  on-line  access  for  inquiries  to  the  data  base 
with  batch  mode  operation  for  periodic  update  of  records  from  a  central 
collecting  agency  or  remote  site.   Hybrid  systems  satisfy  many  requirements 
and  are  simpler  and  less  expensive  than  real-time  systems,  which  require  the 
CPU  to  handle  all  inputs,  outputs,  and  record  updating  immediately  through 
on-line  terminals. 

Timesharing  is  a  term  used  in  the  computer  industry  to  describe  a  proc- 
essing system  with  a  number  of  independent,  relatively  low-speed,  on-line 
terminals.   Each  workstation  has  direct  access  to  the  central  processor. 
Multiprogramming  allows  the  CPU  to  switch  from  one  station  to  another,  doing 
part  of  the  job  required  by  each.   However,  the  speed  of  the  machine  allows 
the  user  at  each  terminal  to  feel  as  if  he/she  is  the  only  one  using  the  com- 
puter.  The  power  of  the  CPU  in  comparison  to  the  complexity  of  its  tasking 
determines  how  close  service  approaches  real-time.   Many  organizations  are  now 
using  minicomputers  in  their  timesharing  system.   This  enables  many  different 
types  of  work  to  be  accomplished  at  one  time,  including  word  processing,  docu- 
ment filing,  telecommunications,  and  various  kinds  of  data  processing. 

Organizations  which  require  constant  communication  with  other  offices  use 
computer  networks  known  as  distributed  processing  systems.   When  these  dis- 
persed computers  are  connected  by  a  communications  network,  the  offices  may 
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then  transmit  messages,  processing  tasks,  and  other  informational  data.   The 
distributed  processing  network  is  actually  an  extension  of  timesharing,  and 
enables  its  users  to  share  some  of  the  most  significant  software  available 
today.   This,  of  course,  reduces  the  amount  of  idle  CPU  time,  making  the  sys- 
tem more  cost  effective  than  a  regular  single  user  real-time  system.   With 
this  increased  availability  of  computer  resources,  many  managers  have  easier 
access  to  the  data  and  are  therefore  more  readily  prepared  to  make  decisions 
for  unusual  problems. 

Unfortunately,  the  processing  speed  is  often  slower.   Since  the  distri- 
buted system  operates  on  the  same  essential  premise  as  the  timesharing  system, 
the  CPUs  are  constantly  switching  around  to  handle  all  tasks.   As  the  number 
of  users  and  associated  complexity  of  processing  requirements  increases,  the 
speed  with  which  they  are  processed  decreases.   In  addition,  the  costs  of  the 
distributed  system  may  not  always  balance  the  quality  of  the  computing  service. 
One  last  potential  disadvantage  of  the  distributed  system  is  its  provision  for 
protecting  the  confidentiality  and  integrity  of  user  programs  and  data  files. 
Although  security  programs  are  constantly  improving  the  protective  qualities 
of  current  systems,  the  methodology  for  cracking  security  systems  is  perhaps 
progressing  at  a  faster  rate.   Of  course,  this  does  not  mean  that  every 
type  of  distributed  system  is  accessible  to  anyone.   Once  the  decision  is  made 
to  include  classified  data  in  the  MMIS,  security  requirements  significantly 
increase  distributed  system  cost  and  complexity.   It  is  believed  that  trade- 
offs will  finally  indicate  that  a  hybrid  system  should  be  developed  wherein 
nonclassified  data  will  be  distributed  and  handled  on-line  while  classified 
data  is  processed  batch  mode  off-line. 

As  noted  previously,  one  of  the  primary  flaws  of  the  MDCS  data  base  is  a 
lack  of  complete  records.   Data  bases  require  that  report  elements  be  clearly 
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defined  and  consistently  organized.   In  turn,  this  requirement  demands  that 
someone  in  the  organization  be  given  the  authority  to  standardize  or  approve 
any  necessary  changes  to  the  data  elements.   Control  of  the  data  leads  to 
control  of  processing  the  software.   With  the  advent  of  application  software 
such  as  data  base  management,  many  users  are  now  able  to  query  the  data  base 
in  a  desired  format  without  any  particular  knowledge  of  programming. 

As  evidenced  in  the  computer  industry  today,  a  user  with  a  clear  and  well 
defined  application  to  his  problem  can  generally  find  a  wide  range  of  techni- 
cal building  blocks.   And  although  the  jargon  of  the  computer  industry, 
"computerese, "  may  inhibit  new  users,  there  are  many  users  with  a  clear  sense 
of  what  computers  do  and  how  development  projects  must  be  managed. 
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VII.   MANAGEMENT  SYSTEMS  APPROACH 

The  systems  approach  to  be  employed  for  the  development  of  the  MMIS  will 
consist  of  four  phases:   (1)  the  Study  Phase,  (2)  the  Design  Phase,  (3)  the 
Development  Phase,  and  (4)  the  Operational  Phase.   Each  phase  will  be  sub- 
jected to  an  iterative  process  of  review  and  will  result  in  a  final  output 
that  can  be  used  for  determining  the  achievements  gained  by  the  activity. 
Figure  6  represents  the  life  cycle  of  the  system  and  products  that  will  give 
utility  for  judging  the  results  of  each  phase.   The  management  approach  will 
be  results  oriented. 

A.   THE  STUDY  PHASE 

This  phase  is  the  initial  effort  to  define  the  overall  MMIS  strategic  plan 
and  development  of  a  systems  performance  specification.   The  effort  will  result 
in  the  assignment  of  a  data  base  manager,  establishment  of  a  study  team,  and 
execution  of  a  fact  finding  process.   During  this  phase,  the  requirements  for 
data  and  report  formats  will  be  identified  and  input/  output  requirements  will 
be  established.   The  development  of  system  flow  charts  and  the  selection  of 
the  most  practical  equipment  (considering  what  is  already  available)  will 
occur. 

The  study  phase  will  culminate  in  a  System  Performance  Specification  (SPS), 
which  describes  the  objectives  of  the  system,  identif icaton  of  the  internal 
and  external  constraints  (such  as  existing  equipments  that  must  be  considered 
for  use)  and  a  feasibility  study  on  the  use  of  converting  currently  collected 
data  into  required  reports.   Another  significant  product  of  the  study  phase  is 
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the  MMIS  Life  Cycle  Management  (LCM)  Plan.   The  plan  will  be  a  dynamic  tool 
that  will  identify  the  manpower  and  resource  requirements  necessary  to  imple- 
ment and  operate  the  MMIS  throughout  its  life  cycles. 

B.  THE  DESIGN  PAHSE 

The  SPS  developed  under  the  study  phase  establishes  the  basis  for  further 
effort  in  the  design  phase.   The  primary  effort  under  the  design  phase  is  to 
evaluate  performance  requirements  and  perform  trade-off  studies  with  current 
computer  technology.   The  efforts  performed  in  the  design  phase  will  extend 
and  expand  the  first  and  second  tier  systems  defined  in  the  study  phase,  and 
will  consolidate  hardware  and  software  functions.   A  Design  Specification  will 
be  prepared  that  delineates  the  system's  architecture  required  to  satisfy 
performance  requirements  and  will  include  MMIS  decisions  as  follows: 

1.  Determination  of  manual  and  equipment  functions/operations; 

2.  Hardware  and  computer  interface  requirements; 

3.  Type  and  functional  programming  requirements; 

4.  Data  base  design; 

5.  Storage  media,  processing  requirements,  and  access  requirements; 

6.  System  and  programming  test  requirements; 

7.  Identification  of  distributed  processing  requirements. 

The  design  phase  will  conclude  based  on  approval  of  the  Design 
Specification  and  acceptance  of  an  updated/revised  MMIS  LCM  Plan. 

C.  THE  DEVELOPMENT  PHASE 

There  are  seven  principle  tasks  to  be  performed  during  the  development 
phase  of  the  MMIS.   They  are: 

1.  Internal/external  computer  programming  (external  is  required  in  a 
distributive  computer  system) ; 

2.  Preparation  of  implementation  plans,  technical  manuals,  and  training 
devices ; 

3.  Acquisition,  installation,  and  debugging  of  new  hardware  (if  required); 
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4.  Preparation  and  verification  testing  of  system/subsystem/component 
performance; 

5.  Preparation  of  Systems  Specification  and  "as  built  specification"; 

6.  Establishment  of  hardware/software  baselines  and  change  control 
procedures ; 

7.  User  reviews,  problem  identification,  and  software  debugging. 

The  basis  of  all  these  tasks  lies  in  the  Design  Specification  prepared  and 
approved  from  the  preceding  phase.   To  ensure  acceptance  of  the  MMIS  during 
the  operational  phase,  a  primary  requirement  is  to  use  a  lot  of  grease  with 
all  the  known  users.   This  requirement  is  best  accomplished  through  the  itera- 
tive process  of  user  reviews  and  proper  indoctrination  training.   Resistance 
is  usually  less  when  users  are  made  part  of  the  development  process.   There 
are  two  major  elements  of  the  development  phase.   They  are: 

1.  Establishment  of  an  operational  system; 

2.  Identification  and  control  of  the  system  through  a  System  Specification 
and  change  control  process. 

Successful  completion  of  the  first  three  phases  brings  to  fruition  an 

operational  computer  based  MMIS.   At  the  conclusion  of  this  phase,  the  MMIS  is 

placed  into  operation. 

D.   THE  OPERATIONAL  PHASE 

The  transition  from  the  development  phase  into  the  operational  phase  is 
hard  to  distinguish.  The  training  that  is  performed  during  the  development 
phase  overlaps  into  the  operational  phase  and  will  continue  on  a  periodic 
basis  during  the  life  cycle  of  the  MMIS.  Users  will  operate  the  system  and 
acquire  the  necessary  information  to  control  the  maintenance  pipeline.  As  new 
systems  emerge  and  data  requirements  change,  it  is  important  to  implement  a 
change  system  that  can  keep  pace  with  the  evolving  requirements  for  new  and 
better  information. 


81 


Even  though  the  system  is  operational,  a  continuous  forum  should  meet  on 
a  periodic  basis  to  discuss  problems,  propose  changes,  and  monitor  change 
efforts.   On  an  annual  basis,  a  team  should  be  formed  to  perform  an  audit  type 
inspection  testing  of  system/subsystem/ component  performance  to  give  the  new 
MMIS  a  checks  and  balance  system  to  ensure  its  integrity. 

E.  STRATEGIC  PLANNING  FOR  THE  IMPROVED  MMIS 

The  degree  of  success  of  an  operational  computer  based  management  infor- 
mation system  can  be  directly  attributed  to  the  strategic  plan  used  throughout 
the  system's  life  cycle.   The  improved  MMIS  will  require  a  comprehensive  man- 
agement plan  that  will  consider  the  management  strategies  to  employ.   The 
strategic  plan  will  be  addressed  as  an  LCM  Plan  and  will  provide  the  practical 
framework  for  the  controlled  growth  of  the  MMIS. 

The  MMIS  LCM  Plan  will  be  a  dynamic  tool  that  documents  information  system 
policy  and  information  resource  management.   The  plan  will  encompass  the  manage- 
ment structure  and  responsibilities,  informational  and  equipment  requirements, 
project  activities,  schedules  and  milestones,  and  cost  controls.  The  dynamism 
of  the  plan  will  be  represented  by  continual  change  that  results  from  evolving 
innovations  in  technology  as  well  as  decisions  associated  with  informational 
requirements.   The  plan  will  be  an  integral  part  of  the  MMIS  and  will  give  the 
foundation  of  total  planning  for  effective,  efficient,  and  affordable  accom- 
plishment of  mission  information  system  needs  during  the  system's  life  cycle. 

F.  STATEGIC  PLANNING  RESPONSIBILITIES 

The  MMIS  LCM  Plan  will  be  prepared  by  the  lead  activity  responsible  for  Data 
Base  Management  (DBM) .   The  NAVAIRSYSCOM  should  designate  the  PACMISTESTCEN  as 
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the  activity  responsible  for  the  MMIS  DBM.   The  LCM  Plan  will  be  prepared  and 
maintained  current  by  the  PACMISTESTCEN. 

The  PACMISTESTCEN  is  responsible  for  establishing  the  management  hierarchy 
for  development  of  strategic  plans  and  definition  of  data  and  informational 
requirements.   The  PACMISTESTCEN  is  in  the  best  position  to  accomplish  this  job 
since  their  awareness  of  informational  needs  for  accomplishing  mission  objec- 
tives at  the  strategic,  tactical,  and  operational  levels  cannot  be  matched  by 
any  other  organization.   The  strategic  plans  will  be  formulated  from  every 
perspective  with  sensitivity  to  all  levels  of  informational  requirements, 
emphasizing  user  selectivity  and  accessibility. 

G.   MMIS  DATA  BASE  MANAGER 

The  PACMISTESTCEN  will  organize  internally  to  build  the  MMIS  strategic 
plan  and  initiate  development  efforts.   A  data  base  manager  will  be  assigned 
who  has  the  reputation  and  expertise  to  represent  the  PACMISTESTCEN  within 
NAVAIRSYSCOM  and  other  activities.   The  data  base  manager  will  be  required  to 
make  significant  contributions  to  strategic  planning  and  system  development 
efforts  by  being  fully  aware  of  three  key  elements: 

1.  The  composition  of  the  maintenance  pipeline  currently  consists  of  the 
informational  requirements  for  effective  monitoring  and  control. 

2.  Knowledge  of  MMIS  user  informational/data  requirements  from  field  and 
command  level  prospectives ; 

3.  The  ability  to  effectively  interface  with  activities /commands  outside 
the  NAVAIRSYSCOM  to  ensure  proper  integration  of  all  necessary  data  into 
the  MMIS. 

The  data  base  manager  will  be  required  to  make  decisions  relative  to  system 
formulation  and  informational  requirements;  to  this  avail,  the  PACMISTESTCEN 
designated  data  base  manager  will  be  a  GM-14,  temporarily  staffed  to  the  Wea- 
pons System  Directorate  for  a  period  of  one  year  during  intensive  initial 
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system  development.   Due  to  the  relative  significance  of  the  initial  develop- 
ment effort  and  the  lack  of  any  means  of  obtaining  the  necessary  data  to  manage 
the  maintenance  pipeline,  heavy  emphasis  will  be  placed  on  expediting  system 
development  that  will  necessitate  the  data  base  manager  to  be  dedicated  to 
MMIS  development  without  collateral  duties. 

The  data  base  manager  will  be  the  focal  point  for  strategic  plan 
development.   NAVAIRSYSCOM  (AIR-420)  will  retain  policy  decisions  and  plan 
approval  responsibilities.   The  data  base  manager  will  work  closely  with 
NAVAIRSYSCOM  (AIR-420)  in  the  preparation  of  the  MMIS  LCM  Plan  to  ensure 
cor  istency  with  current  and  future  NAVAIR  policies  and  initiatives. 

H.   MMIS  STUDY  TEAM 

The  data  base  manager  will  draw  together  a  study  team  that  will  be 
comprised  of  representatives  from  all  future  users  of  the  MMIS,  computer 
specialists  tasked  with  equipment  and  programming  responsibilities,  and  other 
significant  contributes  to  the  proper  development  and  implementation  of  the 
MMIS.   The  study  team  will  be  the  nucleus  for  defining  system  performance 
requirements  and  will  be  the  main  contributor  of  the  MMIS  LCM  Plan. 

Meetings  of  the  members  of  the  study  team  will  be  held  on  a  monthly  basis 
to  discuss  user  requirements,  develop  performance  requirements,  and  to  review 
action  assignments.   During  the  study  and  design  phases,  meetings  may  be  called 
on  a  more  frequent  basis  to  allow  for  expediting  system  definition  and  develop- 
ment efforts.   The  data  base  manager  and  other  study  team  members  may  elect  to 
interview  others  to  obtain  information  necessary  to  further  understand  poten- 
tial areas  that  might  require  data  or  information,  or  provide  a  source  of 
input  data. 
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I.   MMIS  INFORMATION  AND  EQUIPMENT  REQUIREMENTS 

The  reason  for  establishing  the  MMIS  is  to  provide  users  with  information 
and  data  in  a  form  and  frequency  that  will  improve  the  maintenance  management 
function.   The  identification  and  development  of  these  requirements  will  be 
contained  in  the  MMIS  LCM  Plan  and  will  be  done  through  a  fact  finding  process 
that  allows  future  users  to  convey  their  ideas  and  reporting  requirements. 
The  fact  finding  process  will  be  accomplished  by  the  data  base  manager  and 
study  team  during  the  study  phase.   User  data  requirements  will  be  documented 
in  broad  terms  in  the  MMIS  LCM  Plan,  with  expanded  requirements  being  identi- 
fied in  the  SPS. 

During  the  design  phase,  user  data  requirements  will  be  measured  against  a 
number  of  system  considerations  and  trade-offs.   The  feasibility  of  obtaining 
and  producing  the  necessary  information  to  satisfy  user  needs  will  be  deter- 
mined.  The  MMIS  LCM  Plan  will  be  updated/revised  to  reflect  informational 
decisions  made  during  this  phase. 

J.   PROJECT  ACTIVITIES  AND  THE  MMIS  LCM  PLAN 

The  MMIS  LCM  Plan  will  have  a  comprehensive  section  on  the  who,  what,  when, 
and  where  of  all  project  activities  required  during  the  initial  phase  of  system 
development  through  implementation.   The  MMIS  LCM  Plan  will  be  updated/revised 
as  system  requirements  evolve  into  operational  status.   The  plan  will  be  dyna- 
mic, even  in  the  operational  phase,  by  delineating  events  that  will  be  required 
throughout  the  system  life  cycle.   Examples  of  activities  that  will  be  addressed 
are  future  system  audits  and  performance  appraisals,  new  development  initiatives/ 
system  changes,  and  establishment  of  technological  advancements.   The  MMIS  LCM 
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an  will  be  maintained  during  the  MMIS  complete  life  cycle  and  will  be  used 
for  guidance  and  providing  information  on  planned  project  activities. 

K.   MMIS  SCHEDULES,  MILESTONES,  AND  COST  CONTROLS 

The  initiation  of  a  master  plan  for  establishing  schedules  for  tasks  and 
milestones  for  events  is  necessary.   This  will  be  accomplished  through  the  use 
of  a  management  analysis  and  planning  network  known  as  Critical  Path  Method 
(CPM)  networking,  which  is  similar  to  the  Program  Evaluation  Re\ iew  Technique. 
CPM  graphically  displays  task  requirements  and  relationships,  and  forces  man- 
agement to  construct  a  network  which  will  act  as  a  master  plan  for  accomplishing 
project  activities. 

CPM  will  be  employed  to  control  the  complex  project  events  associated  with 
the  development  of  the  MMIS.   The  CPM  network  insures  total  planning  from  pro- 
gram initiation  to  the  operational  phase.   CPM  will  be  used  to  identify 
schedules  for  task  activities  and  will  project  MMIS  program  milestones.   The 
CPM  networking  process  will  identify  a  critical  path  which  will  require  manage- 
ment focus  and  continual  attention.   The  CPM  networking  techniques  will  assist 
the  DBM  in  controlling  loss  of  time  and  project  costs. 

Project  costs  will  be  results  and  output  oriented.   The  MMIS  LCM  Plan  will 
identify  man-hour  requirements  and  costs  associated  for  completion  of  major 
milestones.   A  detailed  cost  analysis  will  be  performed  in  conjunction  with 
CPM  network  events  and  actual  expenses  will  be  assessed  against  program 
accomplishments.   Cost  projections  will  be  refined  as  more  definitive  system 
requirements  are  developed.   Cost  considerations  will  receive  the  micromanage- 
ment  attention  to  achieve  program  objectives  within  cost  projections. 
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MAGNETIC  TAPE  RECORD  DESCRIPTION 


CHARACTER 

FIELD 

CARD 

POSITION 

NAME 

LENGTH 

1-20 

C.I.I.D. 

20 

21-37 

C.I.  SERIAL  NO. 

17 

38-43 

C.I.  DATE 

6 

44-47 

C.I.  TIME 

4 

48-52 

"SMDCS"  or  "FMDCS" 

5 

53-56 

REPORTING  ACTIVITY 

4 

57-80 

ITEM/MK/MOD 

24 

2 

1-20 

ITEM  PART  NO. 

20 

2 

21-37 

ITEM  SERIAL  NO. 

17 

2 

38-80 

MATED  ITEM  SERIAL  NO. 

43 

3 

1-24 

MATED  ITEM  SERIAL  NO. 

24 

3 

25-30 

ACTION  DATE 

6 

3 

31-34 

ACTION  TIME 

4 

3 

35-36 

OPERATION  CODE 

2 

3 

37-51 

TEST  EQUIPMENT  TEC, 
SERIAL  NO. 

5 

3 

52-53 

ITEM  SOURCES 

2 

3 

54-55 

MATED  ITEM  SOURCE 

2 

3 

56-57 

MATED  ITEM  SOURCE 

2 

3 

58-59 

MATED  ITEM  SOURCE 

2 

3 

60 

TEST/ INSPECTION  RESULT 

1 

3 

61 

MATED  SECTION  RESULT 

1 

3 

62 

MATED  SECTION  RESULT 

1 

3 

63 

MATED  SECTION  RESULT 

1 

3 

64-66 

DISPOSITION  CODE 

3 

3 

67 

CONDITION  CODE 

1 

3 

68 

DEFECT  CODE 

1 

3 

69-72 

NALC 

4 

3 

73-80 

FSCM 

8 

4 

1-4 

TEC 

4 

4 

5-13 

WUC 

9 

4 

14-30 

NUN 

17 

4 

31-44 

LOT  NO 

14 

4 

45-49 

MGFR.  DATE 

5 

4 

50-54 

Tl 

5 

4 

55-59 

T2 

5 

4 

60-80 

T3 

5 

5 

1-80 

FAILURE  CODES 

80 

6 

1-80 

FAILURE  CODES 

80 

7 

1-6 

DATE  ASSIGNED 

6 

7 

7 

TRANSFERRED 

1 

7 

8-12 

TO/FROM  ACTIVITY 

5 

7 

13-80 

JOB  ORDER  NO 

68 

8 

1-80 

REMARKS 

80 

9 

1-80 

REMARKS 

80 

Figure  1.   PHOENIX  Maintenance  Record  Format 
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Figure  3.   SPARROW  Configuration  Summary  Form. 
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